* Re: How to quickly write cleanmarkers to jffs2 partitions?
From: Jaap-Jan Boor @ 2006-03-02 17:07 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <200603021706.14618.david.jander@protonic.nl>
Hi David,
I indeed did write a small program that only writes the cleanmarkers
in all flash blocks used for jffs2. We assume (and check) all flash
sectors
are erased already.
Jaap-Jan
On 2-mrt-2006, at 17:06, David Jander wrote:
>
> Hi,
>
> I was wondering if there is a trick or common technique I am
> ignoring to make
> this more efficient:
>
> This is for a 2.4 kernel based system.
> In production we use either u-boot or a NFS mounted linux system to
> erase
> flash and write jffs2 partitions to it. The jffs2 images are small
> (not
> padded to full partition size to save programming time), but the
> partitions
> are rather big (12 Mbyte in one case). Problem is that when booting
> for the
> first time, one has to wait several minutes (during which the
> system is more
> or less useless and busy) to get all cleanmarkers written to flash
> by the
> jffs2 gc thread. This huge delay is rather unacceptable for
> production, so we
> are looking for a work-around.
>
> One option would be to make jffs2 images that are padded to full
> partition
> size, but that also isn't very efficient, considering the image is
> only about
> 100k in beginning and the partition is 12 Mbyte in size. That would
> take a
> lot of time programming flash (less time than having the jffs2
> driver fix
> this nevertheless).
>
> Another option is making a little program that writes cleanmarkers
> in every
> eraseblock starting from the first completely empty one in a
> partition before
> mounting that partition for the very first time after flashing.
>
> Since this seems to me like a common situation, I'd like to know if
> anybody
> knows about a better solution, or if anybody has already dealt with
> this
> before.
>
> Greetings,
>
> --
> David Jander
> Protonic Holland.
> tel.: +31 (0) 229 212928
> fax.: +31 (0) 229 210930
> Factorij 36 / 1689 AL Zwaag
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> --
> This message has been scanned for viruses and is believed to be clean
>
____
J.G.J. Boor Anton Philipsweg 1
Software Engineer 1223 KZ Hilversum
AimSys bv tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum jjboor at aimsys dot nl
^ permalink raw reply
* incorrect rmo_top handling in prom_init
From: Olaf Hering @ 2006-03-02 18:55 UTC (permalink / raw)
To: linuxppc-dev
My iBook1 has 2 memory regions in reg. Depending on how I boot it
(vmlinux+initrd) or zImage.initrd, it will not boot with current Linus
tree.
rmo_top should be 160MB instead of 32MB.
0 > dev /memory .properties
name memory
device_type memory
reg 00000000 02000000
02000000 08000000
slot-names 00000003
DIMM0/BUILT-IN
DIMM1/J12
available 00003000 09bfd000
dimm-info 8000040c 08040000 00000000 00000000 0000bc00 00000000 000000be 00bdbf00
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8008040c 0a014000 01a08000 80080001 8f040601 01000fa0 60000014 14143220
20102010 00000000 00000000 00000000 00000000 00000000 00000000 00001237
7fd50000 00000000 01373634 56313641 33445434 44444700 00000001 00519900
00000001 01020105 09030701 02020000 00000000 00000000 00000000 000064c7
dimm-types SDRAM
SDRAM
dimm-speeds
PC100-222S
ok
0 > boot enet:1.1.1.3,yaboot
CLIENT: 000a27aa0f20 1.1.1.1
SERVER: 0003938574cc 1.1.1.3
Transfer FILE: yaboot \
TFTP-actual=406ff TFTP-adler32=e64fd05f load-size=406ff adler32=e64fd05f
Loading ELF
yaboot starting: loaded at 0x00200000-0x00235ed8 (0x0/0x200000/0xff80a290;sp: 0x0023eb14)
CLIENT: 000a27aa0f20 1.1.1.1
SERVER: 0003938574cc 1.1.1.3
Transfer FILE: yaboot.conf
TFTP-actual=333 TFTP-adler32=1af6149c Config file 'yaboot.conf' read, 819 bytes
fooo xxx yaboot.conf
Welcome to yaboot version 1.3.13.SuSE
booted from '/pci@f4000000/ethernet:1.1.1.3,yaboot'
Enter "help" to get some basic usage information
boot: i
Please wait, loading kernel...
CLIENT: 000a27aa0f20 1.1.1.1
SERVER: 0003938574cc 1.1.1.3
Transfer FILE: inst32
TFTP-actual=798ffb TFTP-adler32=aaf3b8f5 Allocated 0x00900000 bytes for executable @ 0x00400000
Elf32 kernel loaded...
SuSE Linux zImage starting: loaded at 0x00400000-0x00b93cbc (0x1000000/0x0/0xff80a290; sp: 0x0023e9a4)
uncompressing ELF header done. (0x00000100 bytes)
Allocated 0x0078dfb0 bytes for kernel @ 0x02000000
Allocated 0x005aacd6 bytes for initrd @ 0x0278e000
uncompressing kernel done. (0x00431788 bytes)
entering kernel at 0x02010000(278e000/5aacd6/ff80a290)
OF stdout device is: /packages/telnet
initrd_start=0x0278e000
initrd_end=0x02d38cd6
command line:
root_addr_cells: 00000001
root_size_cells: 00000001
scanning memory:
node /memory@0 :
00000000 02000000
02000000 08000000
memory layout at init:
memory_limit : 00000000 (16 MB aligned)
alloc_bottom : 02d39000
alloc_top : 02000000
alloc_top_hi : 0a000000
rmo_top : 02000000
ram_top : 0a000000
Booting CPU hw index = 0x00000000
copying OF device tree ...
foo
starting device tree allocs at 02d39000
alloc_up(00100000, 00001000)
Can't allocate initial device-tree chunk
DEFAULT CATCH!, code=900 at %SRR0: 024017a4 %SRR1: 00083030
ok
0 >
^ permalink raw reply
* Unsafe pte_update() in do_page_fault() (4xx and Book-E)
From: Eugene Surovegin @ 2006-03-02 20:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Kumar Gala
Hi!
For the last couple of days I was debugging rare
swap_dup: Bad swap file entry 0x00000080
errors in my custom 2.4 kernel running on 405GPr system.
My current theory is that this error is caused by the special lazy
dcache/icache flush handling on 4xx and BookE. Because this code in my
2.4 was actually a backport from 2.6, I think we have a problem in
current 2.6 as well.
Here is what I think happens. On 4xx/BookE we use execute bit to
deffer dcache to icache flush, in do_page_fault() we flush page when
execute trap triggers and enable _PAGE_HWEXEC bit in PTE.
Unfortunately, we don't lock this PTE and it's possible that after
pte_present() check but _before_ pte_update() call this particular
page was purged from the memory, e.g. because of extreme memory
pressure (of course, I'm assuming enabled preempt).
If this happens, pte_update() sets _PAGE_HWEXEC bit in just cleared
PTE. Sometime later, another page fault happens for this page, but
because of that set bit, pte_none() test in handle_pte_fault() fails,
and we continue along the wrong path, thinking that this PTE was
swapped out to the swap file, and this triggers swap_dup error I
mentioned at the beginning.
_PAGE_HWXEC is 0x200 on 405GPr, and because swap entry is PTE shifted
2 bits to the right, we get that "0x00000080" value.
Paul, does my theory make any sense? I cannot test 2.6 on our hw. So
far, after I added additional page_table_lock locking to my 2.4 in
do_page_fault(), I haven't seen these errors, but it's too early to be
100% sure :).
I'll make a patch for 2.6 if you think my analysis is correct.
--
Eugene
^ permalink raw reply
* [PATCH] powerpc: tidy-up of_register_driver()/driver_register() return values
From: Bjorn Helgaas @ 2006-03-02 23:16 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt; +Cc: Andrew Morton, linuxppc-dev
Remove the assumption that driver_register() returns the number of
devices bound to the driver. In fact, it returns zero for success
or a negative error value.
Nobody uses the return value of of_register_driver() anyway.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work-mm4/arch/powerpc/kernel/of_device.c
===================================================================
--- work-mm4.orig/arch/powerpc/kernel/of_device.c 2006-03-01 15:37:13.000000000 -0700
+++ work-mm4/arch/powerpc/kernel/of_device.c 2006-03-02 10:46:58.000000000 -0700
@@ -147,15 +147,12 @@
int of_register_driver(struct of_platform_driver *drv)
{
- int count = 0;
-
/* initialize common driver fields */
drv->driver.name = drv->name;
drv->driver.bus = &of_platform_bus_type;
/* register with core */
- count = driver_register(&drv->driver);
- return count ? count : 1;
+ return driver_register(&drv->driver);
}
void of_unregister_driver(struct of_platform_driver *drv)
Index: work-mm4/drivers/macintosh/smu.c
===================================================================
--- work-mm4.orig/drivers/macintosh/smu.c 2006-03-01 15:37:41.000000000 -0700
+++ work-mm4/drivers/macintosh/smu.c 2006-03-02 10:47:30.000000000 -0700
@@ -630,8 +630,6 @@
static int __init smu_init_sysfs(void)
{
- int rc;
-
/*
* Due to sysfs bogosity, a sysdev is not a real device, so
* we should in fact create both if we want sysdev semantics
@@ -640,7 +638,7 @@
* I'm a bit too far from figuring out how that works with those
* new chipsets, but that will come back and bite us
*/
- rc = of_register_driver(&smu_of_platform_driver);
+ of_register_driver(&smu_of_platform_driver);
return 0;
}
^ permalink raw reply
* Re: incorrect rmo_top handling in prom_init
From: Benjamin Herrenschmidt @ 2006-03-02 23:35 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060302185509.GA14235@suse.de>
On Thu, 2006-03-02 at 19:55 +0100, Olaf Hering wrote:
> My iBook1 has 2 memory regions in reg. Depending on how I boot it
> (vmlinux+initrd) or zImage.initrd, it will not boot with current Linus
> tree.
> rmo_top should be 160MB instead of 32MB.
Does that fix it ?
Index: linux-work/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/prom_init.c 2006-03-01 11:48:27.000000000 +1100
+++ linux-work/arch/powerpc/kernel/prom_init.c 2006-03-03 10:34:30.000000000 +1100
@@ -978,7 +978,7 @@
if (size == 0)
continue;
prom_debug(" %x %x\n", base, size);
- if (base == 0)
+ if (base == 0 && (RELOC(of_platform) & PLATFORM_LPAR))
RELOC(rmo_top) = size;
if ((base + size) > RELOC(ram_top))
RELOC(ram_top) = base + size;
^ permalink raw reply
* [PATCH] macintosh: tidy-up driver_register() return values
From: Bjorn Helgaas @ 2006-03-02 23:18 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt; +Cc: Andrew Morton, linuxppc-dev
Remove the assumption that driver_register() returns the number of
devices bound to the driver. In fact, it returns zero for success
or a negative error value.
All callers of macio_register_driver() either ignore the return value
or return it as the return value of a module_init() function.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work-mm4/drivers/macintosh/macio_asic.c
===================================================================
--- work-mm4.orig/drivers/macintosh/macio_asic.c 2006-03-01 15:37:15.000000000 -0700
+++ work-mm4/drivers/macintosh/macio_asic.c 2006-03-02 12:57:05.000000000 -0700
@@ -550,15 +550,12 @@
*/
int macio_register_driver(struct macio_driver *drv)
{
- int count = 0;
-
/* initialize common driver fields */
drv->driver.name = drv->name;
drv->driver.bus = &macio_bus_type;
/* register with core */
- count = driver_register(&drv->driver);
- return count ? count : 1;
+ return driver_register(&drv->driver);
}
/**
^ permalink raw reply
* Linux on PPC
From: rtos @ 2006-03-03 2:01 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
Hi,
We have a customized board running on IBM PPC 750. The customer boot loader
is provided by the vendor.
Also, the vendor has provided the BSP on vxworks.
We are planning to use linux on this processor. What are the steps involved
in booting the board with linux.
Which linux to be used and what are the procedures involved. I dint come
across a documents which had these details.
I am new to the linux front. So any help is highly appreciated.
thanks
[-- Attachment #2: Type: text/html, Size: 615 bytes --]
^ permalink raw reply
* Re: Linux on PPC
From: Frank @ 2006-03-03 2:23 UTC (permalink / raw)
To: rtos, linuxppc-embedded
In-Reply-To: <190edfbd0603021801g5505cab9h8e285fdc7bf476d1@mail.gmail.com>
--- rtosrtososrtosgmaigmail> wrote:
> Hi,
>
> We have a customized board running on IBM PPC PPC. The
> customer boot loader
> is provided by the vendor.
> Also, the vendor has provided the BSP BSPvxwovxworks
> We are planning to use linulinuxthis processor. What are the
> steps involved
> in booting the board with linulinux Which linulinuxbe used and
what are the procedures involved. I
> dint come
> across a documents which had these details.
>
> I am new to the linulinuxnt. So any help is highly
> appreciated.
>
> thanks
I recommend using u-boot and the ELDK from denx.de
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Unsafe pte_update() in do_page_fault() (4xx and Book-E)
From: Benjamin Herrenschmidt @ 2006-03-03 3:43 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, Kumar Gala
In-Reply-To: <20060302202634.GA14387@gate.ebshome.net>
> If this happens, pte_update() sets _PAGE_HWEXEC bit in just cleared
> PTE. Sometime later, another page fault happens for this page, but
> because of that set bit, pte_none() test in handle_pte_fault() fails,
> and we continue along the wrong path, thinking that this PTE was
> swapped out to the swap file, and this triggers swap_dup error I
> mentioned at the beginning.
Can we preempt at that point ? As tehre is no SMP 4xx that I know of
preempt would be the only cause for such a race ...
Ben.
^ permalink raw reply
* Re: Unsafe pte_update() in do_page_fault() (4xx and Book-E)
From: Eugene Surovegin @ 2006-03-03 3:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Kumar Gala
In-Reply-To: <1141357383.3888.19.camel@localhost.localdomain>
On Fri, Mar 03, 2006 at 02:43:02PM +1100, Benjamin Herrenschmidt wrote:
>
> > If this happens, pte_update() sets _PAGE_HWEXEC bit in just cleared
> > PTE. Sometime later, another page fault happens for this page, but
> > because of that set bit, pte_none() test in handle_pte_fault() fails,
> > and we continue along the wrong path, thinking that this PTE was
> > swapped out to the swap file, and this triggers swap_dup error I
> > mentioned at the beginning.
>
> Can we preempt at that point ? As tehre is no SMP 4xx that I know of
> preempt would be the only cause for such a race ...
Yes, as I mentioned in the original post, I'm running preempt enabled
kernel.
--
Eugene
^ permalink raw reply
* Re: Linux on PPC
From: nreddy @ 2006-03-03 5:09 UTC (permalink / raw)
To: rtos; +Cc: linuxppc-embedded
In-Reply-To: <190edfbd0603021801g5505cab9h8e285fdc7bf476d1@mail.gmail.com>
You can easily migrate to linux environment.
1. You can use u-boot as a boot loader.
2. You can choose any standard linux kernel but you may have to do some
R&D on it to port to your board.
Insted you can buy Montavista Linux, so that you can get support also.
And also there are many mailing lists where yo ucan get tremendous help
on linux.
Thanks,
Nagi
> Hi,
>
> We have a customized board running on IBM PPC 750. The customer boot
> loader
> is provided by the vendor.
> Also, the vendor has provided the BSP on vxworks.
>
> We are planning to use linux on this processor. What are the steps
> involved
> in booting the board with linux.
> Which linux to be used and what are the procedures involved. I dint come
> across a documents which had these details.
>
> I am new to the linux front. So any help is highly appreciated.
>
> thanks
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Linux on PPC
From: David Hawkins @ 2006-03-03 5:10 UTC (permalink / raw)
To: rtos; +Cc: linuxppc-embedded
In-Reply-To: <190edfbd0603021801g5505cab9h8e285fdc7bf476d1@mail.gmail.com>
Hiya,
I'm no expert in this, but here's the basics;
> We have a customized board running on IBM PPC 750. The customer boot
> loader is provided by the vendor. Also, the vendor has provided
> the BSP on vxworks.
The PPC 750 is a fairly old processor, so there will be Linux
support for it. For example, I picked up a couple of Artesyn
PrPMC boards that contain a PPC 750, and this board can run
Linux, though I have not had time to try booting it yet.
If the vendor provided the VxWorks BSP, then hopefully they
also provided you with the physical memory map of the board.
This is what you really need to get another bootloader (eg. U-Boot)
and Linux up-and-running. If the vendor will provide schematics
for the board, that would also help (hey, it never hurts to
ask for them).
> We are planning to use linux on this processor. What are the steps
> involved in booting the board with linux.
> Which linux to be used and what are the procedures involved. I dint come
> across a documents which had these details.
>
> I am new to the linux front. So any help is highly appreciated.
>
Step 1. Get the memory map of the board.
Step 2. Find a PPC 750 port in the Linux source.
For example, in the 2.6 series kernel, the place to start
looking is under arch/ppc/platforms. grep -Ie 750 shows
up some of the PPC 750 based systems.
chestnut.c 750FX/GX evaluation board
katana.c Looks like one too
prpmc750.c Looks like a Motorola board
Look at the comments in the code, look at the memory map
of the reference board versus your custom board. There is
a very good chance that the custom board is based on a
reference design - thats the whole point of them.
Step 3. Build a minimal kernel
Step 4. Boot
Step 5. Purchase a BDI2000 JTAG debugger and use it to figure
out why Step 4 didn't work.
Repeat at Step 3.
When I get time to play with my Artesyn board, I'll go back to
the katana.c file, the grep above had some comments about Artesyn
boards. If it fails to boot, I'll use the BDI2000 to see where it
dies and go from there.
Once you can boot Linux, you might decide that the custom bootloader
on the board is inflexible. The U-Boot bootloader is very nice
and will have support for other 750-based boards, it shouldn't
take too much to port that too. But first, try to get a Linux
kernel booted, even if it has a hard-wired command line.
Also take a look over on the Freescale web site, search for
'porting linux', it'll show up AN2145, AN2222, AN2579, and
a bunch of other application notes. They'll give you an idea
of what it takes to port to a new processor.
> I am new to the linux front. So any help is highly appreciated.
So it depends how much time you have versus how much you
want to spend.
There are also commercial companies that will do the job for you.
If you can come up with the memory map and hardware details of
the board, you could always post a request on this list, and
I am sure there are people reading this list that would
respond. (I'm not one of them though, so I'm not trying to
drum up business ok)
Regards,
Dave
^ permalink raw reply
* [PATCH] powerpc: Fix old g5 issues with windfarm
From: Benjamin Herrenschmidt @ 2006-03-03 6:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Linux Kernel list
Some of the windfarm sensor modules can initialize on old machines that
don't have full windfarm support like non-dual core desktop G5s.
Unfortunately, by doing so, they would trigger a bug in their matching
algorithm causing them to attach to the wrong bus, thus triggering
issues with the i2c core and breaking the thermal driver.
This patch fixes the probing issue (so that they will work when a
windfarm port is done to these machines) and also prevents for now
windfarm to load at all on these machines that still use therm_pm72 to
avoid wasting resources.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/drivers/macintosh/windfarm_lm75_sensor.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_lm75_sensor.c 2006-03-03 16:02:56.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_lm75_sensor.c 2006-03-03 16:41:01.000000000 +1100
@@ -25,9 +25,9 @@
#include "windfarm.h"
-#define VERSION "0.1"
+#define VERSION "0.2"
-#define DEBUG
+#undef DEBUG
#ifdef DEBUG
#define DBG(args...) printk(args)
@@ -113,6 +113,7 @@ static struct wf_lm75_sensor *wf_lm75_cr
const char *loc)
{
struct wf_lm75_sensor *lm;
+ int rc;
DBG("wf_lm75: creating %s device at address 0x%02x\n",
ds1775 ? "ds1775" : "lm75", addr);
@@ -139,9 +140,11 @@ static struct wf_lm75_sensor *wf_lm75_cr
lm->i2c.driver = &wf_lm75_driver;
strncpy(lm->i2c.name, lm->sens.name, I2C_NAME_SIZE-1);
- if (i2c_attach_client(&lm->i2c)) {
- printk(KERN_ERR "windfarm: failed to attach %s %s to i2c\n",
- ds1775 ? "ds1775" : "lm75", lm->i2c.name);
+ rc = i2c_attach_client(&lm->i2c);
+ if (rc) {
+ printk(KERN_ERR "windfarm: failed to attach %s %s to i2c,"
+ " err %d\n", ds1775 ? "ds1775" : "lm75",
+ lm->i2c.name, rc);
goto fail;
}
@@ -175,16 +178,22 @@ static int wf_lm75_attach(struct i2c_ada
(dev = of_get_next_child(busnode, dev)) != NULL;) {
const char *loc =
get_property(dev, "hwsensor-location", NULL);
- u32 *reg = (u32 *)get_property(dev, "reg", NULL);
- DBG(" dev: %s... (loc: %p, reg: %p)\n", dev->name, loc, reg);
- if (loc == NULL || reg == NULL)
+ u8 addr;
+
+ /* We must re-match the adapter in order to properly check
+ * the channel on multibus setups
+ */
+ if (!pmac_i2c_match_adapter(dev, adapter))
+ continue;
+ addr = pmac_i2c_get_dev_addr(dev);
+ if (loc == NULL || addr == 0)
continue;
/* real lm75 */
if (device_is_compatible(dev, "lm75"))
- wf_lm75_create(adapter, *reg, 0, loc);
+ wf_lm75_create(adapter, addr, 0, loc);
/* ds1775 (compatible, better resolution */
else if (device_is_compatible(dev, "ds1775"))
- wf_lm75_create(adapter, *reg, 1, loc);
+ wf_lm75_create(adapter, addr, 1, loc);
}
return 0;
}
@@ -206,6 +215,11 @@ static int wf_lm75_detach(struct i2c_cli
static int __init wf_lm75_sensor_init(void)
{
+ /* Don't register on old machines that use therm_pm72 for now */
+ if (machine_is_compatible("PowerMac7,2") ||
+ machine_is_compatible("PowerMac7,3") ||
+ machine_is_compatible("RackMac3,1"))
+ return -ENODEV;
return i2c_add_driver(&wf_lm75_driver);
}
Index: linux-work/drivers/macintosh/windfarm_max6690_sensor.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_max6690_sensor.c 2006-02-17 14:38:40.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_max6690_sensor.c 2006-03-03 16:40:05.000000000 +1100
@@ -17,7 +17,7 @@
#include "windfarm.h"
-#define VERSION "0.1"
+#define VERSION "0.2"
/* This currently only exports the external temperature sensor,
since that's all the control loops need. */
@@ -81,7 +81,7 @@ static struct wf_sensor_ops wf_max6690_o
static void wf_max6690_create(struct i2c_adapter *adapter, u8 addr)
{
struct wf_6690_sensor *max;
- char *name = "u4-temp";
+ char *name = "backside-temp";
max = kzalloc(sizeof(struct wf_6690_sensor), GFP_KERNEL);
if (max == NULL) {
@@ -118,7 +118,6 @@ static int wf_max6690_attach(struct i2c_
struct device_node *busnode, *dev = NULL;
struct pmac_i2c_bus *bus;
const char *loc;
- u32 *reg;
bus = pmac_i2c_adapter_to_bus(adapter);
if (bus == NULL)
@@ -126,16 +125,23 @@ static int wf_max6690_attach(struct i2c_
busnode = pmac_i2c_get_bus_node(bus);
while ((dev = of_get_next_child(busnode, dev)) != NULL) {
+ u8 addr;
+
+ /* We must re-match the adapter in order to properly check
+ * the channel on multibus setups
+ */
+ if (!pmac_i2c_match_adapter(dev, adapter))
+ continue;
if (!device_is_compatible(dev, "max6690"))
continue;
+ addr = pmac_i2c_get_dev_addr(dev);
loc = get_property(dev, "hwsensor-location", NULL);
- reg = (u32 *) get_property(dev, "reg", NULL);
- if (!loc || !reg)
+ if (loc == NULL || addr == 0)
continue;
- printk("found max6690, loc=%s reg=%x\n", loc, *reg);
+ printk("found max6690, loc=%s addr=0x%02x\n", loc, addr);
if (strcmp(loc, "BACKSIDE"))
continue;
- wf_max6690_create(adapter, *reg);
+ wf_max6690_create(adapter, addr);
}
return 0;
@@ -153,6 +159,11 @@ static int wf_max6690_detach(struct i2c_
static int __init wf_max6690_sensor_init(void)
{
+ /* Don't register on old machines that use therm_pm72 for now */
+ if (machine_is_compatible("PowerMac7,2") ||
+ machine_is_compatible("PowerMac7,3") ||
+ machine_is_compatible("RackMac3,1"))
+ return -ENODEV;
return i2c_add_driver(&wf_max6690_driver);
}
Index: linux-work/drivers/macintosh/windfarm_pm112.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_pm112.c 2006-02-17 14:38:40.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_pm112.c 2006-03-03 16:24:44.000000000 +1100
@@ -613,7 +613,7 @@ static void pm112_new_sensor(struct wf_s
} else if (!strcmp(sr->name, "slots-power")) {
if (slots_power == NULL && wf_get_sensor(sr) == 0)
slots_power = sr;
- } else if (!strcmp(sr->name, "u4-temp")) {
+ } else if (!strcmp(sr->name, "backside-temp")) {
if (u4_temp == NULL && wf_get_sensor(sr) == 0)
u4_temp = sr;
} else
Index: linux-work/drivers/macintosh/windfarm_cpufreq_clamp.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_cpufreq_clamp.c 2005-11-09 11:49:03.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_cpufreq_clamp.c 2006-03-03 16:42:36.000000000 +1100
@@ -8,6 +8,8 @@
#include <linux/wait.h>
#include <linux/cpufreq.h>
+#include <asm/prom.h>
+
#include "windfarm.h"
#define VERSION "0.3"
@@ -74,6 +76,12 @@ static int __init wf_cpufreq_clamp_init(
{
struct wf_control *clamp;
+ /* Don't register on old machines that use therm_pm72 for now */
+ if (machine_is_compatible("PowerMac7,2") ||
+ machine_is_compatible("PowerMac7,3") ||
+ machine_is_compatible("RackMac3,1"))
+ return -ENODEV;
+
clamp = kmalloc(sizeof(struct wf_control), GFP_KERNEL);
if (clamp == NULL)
return -ENOMEM;
Index: linux-work/drivers/macintosh/windfarm_core.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_core.c 2006-02-17 14:38:40.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_core.c 2006-03-03 16:43:06.000000000 +1100
@@ -35,6 +35,8 @@
#include <linux/platform_device.h>
#include <linux/mutex.h>
+#include <asm/prom.h>
+
#include "windfarm.h"
#define VERSION "0.2"
@@ -465,6 +467,11 @@ static int __init windfarm_core_init(voi
{
DBG("wf: core loaded\n");
+ /* Don't register on old machines that use therm_pm72 for now */
+ if (machine_is_compatible("PowerMac7,2") ||
+ machine_is_compatible("PowerMac7,3") ||
+ machine_is_compatible("RackMac3,1"))
+ return -ENODEV;
platform_device_register(&wf_platform_device);
return 0;
}
^ permalink raw reply
* [PATCH] powerpc: Fix windfarm_pm112 not starting all control loops
From: Benjamin Herrenschmidt @ 2006-03-03 6:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Linux Kernel list
This adds a couple of printk's to windfarm_pm112 to display which
control loops are actually starting and fixes a bug where it would not
start all loops.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/drivers/macintosh/windfarm_pm112.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_pm112.c 2006-03-03 16:24:44.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_pm112.c 2006-03-03 17:04:53.000000000 +1100
@@ -358,6 +358,7 @@ static void backside_fan_tick(void)
return;
if (!backside_tick) {
/* first time; initialize things */
+ printk(KERN_INFO "windfarm: Backside control loop started.\n");
backside_param.min = backside_fan->ops->get_min(backside_fan);
backside_param.max = backside_fan->ops->get_max(backside_fan);
wf_pid_init(&backside_pid, &backside_param);
@@ -407,6 +408,7 @@ static void drive_bay_fan_tick(void)
return;
if (!drive_bay_tick) {
/* first time; initialize things */
+ printk(KERN_INFO "windfarm: Drive bay control loop started.\n");
drive_bay_prm.min = drive_bay_fan->ops->get_min(drive_bay_fan);
drive_bay_prm.max = drive_bay_fan->ops->get_max(drive_bay_fan);
wf_pid_init(&drive_bay_pid, &drive_bay_prm);
@@ -458,6 +460,7 @@ static void slots_fan_tick(void)
return;
if (!slots_started) {
/* first time; initialize things */
+ printk(KERN_INFO "windfarm: Slots control loop started.\n");
wf_pid_init(&slots_pid, &slots_param);
slots_started = 1;
}
@@ -504,6 +507,7 @@ static void pm112_tick(void)
if (!started) {
started = 1;
+ printk(KERN_INFO "windfarm: CPUs control loops started.\n");
for (i = 0; i < nr_cores; ++i) {
if (create_cpu_loop(i) < 0) {
failure_state = FAILURE_PERM;
@@ -594,8 +598,6 @@ static void pm112_new_sensor(struct wf_s
{
unsigned int i;
- if (have_all_sensors)
- return;
if (!strncmp(sr->name, "cpu-temp-", 9)) {
i = sr->name[9] - '0';
if (sr->name[10] == 0 && i < NR_CORES &&
^ permalink raw reply
* RE: boot failure on lite5200b board
From: #LI JIANGGAN# @ 2006-03-03 8:06 UTC (permalink / raw)
To: John Rigby; +Cc: haidong_feng, linuxppc-embedded
In-Reply-To: <4b73d43f0603011652w39fb4393x8879891b7538f0b1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 22566 bytes --]
Thanks John, the Kernel now boots well. However it gives a kernel panic while mounting the root file sysem over NFS:
Looking up port of RPC 100003/2 on 10.190.3.103
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
I couldn't figure out why error 101 /* Network is unreachable */ is given. Below is my current U-boot settings and a snapshot of the booting:
=> printenv
baudrate=115200
autoload=no
ethact=FEC ETHERNET
ethaddr=00:01:9F:00:27:2F
preboot=echo; echo Autostarting. Press any key to abort..; echo
bootdelay=5
hostname=icecube
bootfile=MPC5200/uImage
nv=nfsroot root=/dev/nfs rw nfsroot=10.190.3.113:/opt/eldk/rootfs
netmask=255.255.240.0
ipaddr=10.190.3.144
serverip=10.190.3.103
bootcmd=run net_nfs
netdev=eth0
rootpath=/opt/eldk-4-0/rootfs
ramargs=setenv bootargs root=/dev/ram rw
addip=setenv bootargs ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube:eth0:off panic=1
ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube:eth0:off
net_nfs=tftp 200000 MPC5200/uImage;run nfsargs;bootm
nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
rootfs=10.190.3.103:/opt/eldk-4-0/rootfs
nfsargs=setenv bootargs console=ttyS0,115200 nfsroot=10.190.3.103:/opt/eldk-4-0/nfs root=/dev/nfs rw
stdin=serial
stdout=serial
stderr=serial
Environment size: 882/65532 bytes
=> boot
Using FEC ETHERNET device
TFTP from server 10.190.3.103; our IP address is 10.190.3.144
Filename 'MPC5200/uImage'.
Load address: 0x200000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
###################################
done
Bytes transferred = 1510143 (170aff hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.11.7
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1510079 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
ocp: exit
arch: exit
Linux version 2.6.11.7 (root@bob) (gcc version 3.3.2) #1 Tue Sep 6 22:40:03 UTC 2005
Real-Time Preemption Support (c) Ingo Molnar
Built 1 zonelists
Kernel command line: console=ttyS0,115200 nfsroot=10.190.3.103:/opt/eldk-4-0/nfs root=/dev/nfs rw
PID hash table entries: 2048 (order: 11, 32768 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 256268k available (2336k kernel code, 896k data, 140k init, 0k highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
BUG: scheduling while atomic: swapper/0x00000001/0
caller is schedule+0x50/0xe8
Call trace:
[c0006bd8] dump_stack+0x18/0x28
[c0242818] __sched_text_start+0x69c/0x6a0
[c024286c] schedule+0x50/0xe8
[c0003f00] syscall_exit_work+0x108/0x10c
[c030c578] proc_root_init+0x144/0x150
[c0320000] 0xc0320000
[c02fe624] start_kernel+0x180/0x1b8
[000035fc] 0x35fc
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
softirq RT prio: 24.
desched cpu_callback 2/00000000
desched thread 0 started up.
NET: Registered protocol family 16
PCI: Probing PCI hardware
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
ppdev: user-space parallel port driver
Serial: MPC52xx PSC driver
ttyS0 at MMIO 0xf0002000 (irq = 39) is a MPC52xx PSC
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ipb=132MHz, set clock period to 7
GPIO config: 91051024
ATA invalid: 01000000
ATA hostcnf: 03000000
ATA pio1 : 100a0a00
ATA pio2 : 02040600
XLB Arb cnf: 0000a366
mpc52xx_ide: Setting up IDE interface ide0...
flash chip on the Lite5200/Lite5200B: Found 1 x16 devices at 0x0 in 8-bit bank
flash chip on the Lite5200/Lite5200B: Found 1 x16 devices at 0x1000000 in 8-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
flash chip on the Lite5200/Lite5200B: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 2
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 7 MTD partitions on "flash chip on the Lite5200/Lite5200B":
0x00000000-0x01000000 : "Filesystem"
0x01000000-0x01040000 : "BootLOW"
0x01040000-0x01060000 : "EnvLOW"
0x01060000-0x01d00000 : "Spare"
0x01d00000-0x01f00000 : "Kernel"
0x01f00000-0x01f40000 : "BootHIGH"
0x01f40000-0x01f60000 : "EnvHIGH"
ocp-ohci 02: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
i2c-algo-52xx.o: scanning bus Lite5200 I2C module #1 interface...
................................................................................................................................
i2c-lite5200.o: I2C module #1 installed
i2c-algo-52xx.o: scanning bus Lite5200 I2C module #2 interface...
................................................................................(0x50)..............................................(0x7f)
i2c-lite5200.o: I2C module #2 installed
Advanced Linux Sound Architecture Driver Version 1.0.8 (Thu Jan 13 09:39:32 2005 UTC).
ALSA device list:
No soundcards found.
NET: Registered protocol family 2
IP: routing cache hash table of 256 buckets, 16Kbytes
TCP established hash table entries: 16384 (order: 8, 1048576 bytes)
TCP bind hash table entries: 16384 (order: 7, 917504 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
Looking up port of RPC 100003/2 on 10.190.3.103
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 10.190.3.103
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get mountd port number from server, using default
RPC: sendmsg returned error 101
mount: RPC call returned error 101
Root-NFS: Server returned error -101 while mounting /opt/eldk-4-0/nfs
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or unknown-block(2,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
<0>Rebooting in 180 seconds..
regards,
Jianggan
-----Original Message-----
From: John Rigby [mailto:jcrigby@gmail.com]
Sent: Thu 3/2/2006 8:52
To: #LI JIANGGAN#
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: boot failure on lite5200b board
Here is a uboot setup that works with a freescale kernel:
bootdelay=5
baudrate=115200
preboot=echo;echo Type "run flash_nfs" to mount root filesystem over NFS;echo
autoload=no
ethact=FEC ETHERNET
ramargs=setenv bootargs root=/dev/ram rw
jffs2args=setenv bootargs root=/dev/mtdblock0 rw rootfstype=jffs2
addip=setenv bootargs $(bootargs)
ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):$(netdev):off
panic=1
flash_nfs=run nfsargs addip;bootm $(kernel_addr)
flash_self=run ramargs addip;bootm $(kernel_addr) $(ramdisk_addr)
flash_jffs2=run jffs2args;bootm $(kernel_addr)
net_nfs=tftp 200000 $(bootfile);run nfsargs addip;bootm
netdev=eth0
ethaddr=00:04:9f:22:33:44
bootfile=/tftpboot/uImage
kernel_addr=ffd00000
rootpath=/tftpboot/ltib
filesize=c9d700
fileaddr=1000000
gatewayip=172.27.255.254
netmask=255.255.0.0
ipaddr=172.27.152.99
serverip=172.27.152.5
bootcmd=run net_nfs
nfsargs=setenv bootargs console=ttyS0,115200 root=/dev/nfs rw
nfsroot=$(serverip):$(rootpath)
stdin=serial
stdout=serial
stderr=serial
Change ip info, bootfile, rootpath etc to fit you config.
If you want it to work with Sylvain's kernel then you need to change
ttyS0 to ttyPSC0.
Also add a printenv just before the bootm so you can verify that your
bootargs really are getting set correctly.
On 3/1/06, #LI JIANGGAN# <lijianggan@pmail.ntu.edu.sg> wrote:
>
>
> how about the following U-boot settings:
>
> ..............................
>
>
> Hit any key to stop autoboot: 0
> => printenv
> baudrate=115200
> autoload=no
> ethact=FEC ETHERNET
> ethaddr=00:01:9F:00:27:2F
> preboot=echo; echo Autostarting. Press any key to abort..; echo
> bootdelay=5
> hostname=icecube
> bootfile=MPC5200/uImage
> nv=nfsroot root=/dev/nfs rw nfsroot=10.190.3.113:/opt/eldk/rootfs
> netmask=255.255.240.0
> ipaddr=10.190.3.144
> serverip=10.190.3.103
> bootcmd=run net_nfs
>
> rootfs=root=/dev/nfs rw
> netdev=eth0
> rootpath=/opt/eldk-4-0/rootfs
> nfsargs=setenv bootargs root=/dev/nfs rw
> nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
>
> ramargs=setenv bootargs root=/dev/ram rw
> addip=setenv bootargs
> ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube:eth0:off
> panic=1
> net_nfs=tftp 200000 MPC5200/uImage;run nfsargs addip;bootm
>
> stdin=serial
> stdout=serial
> stderr=serial
>
> Environment size: 738/65532 bytes
> => .
> ................................
>
>
>
> The output is still the same, it hangs after displaying arch:exit
>
> I have also tried the above settings with console set, it gives the same
> output
>
> I am really wondering whether the problem is with the kernel. Sylvain's
> kernel uImage is only around 600k while the one from freescale is 1.4M,
> anybody knows where the difference is?
>
> .....................................
>
> Autostarting. Press any key to abort..
>
> Hit any key to stop autoboot: 0
> Using FEC ETHERNET device
> TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> Filename 'MPC5200/uImage'.
> Load address: 0x200000
>
> Loading:
> #################################################################
>
> #################################################################
>
> #################################################################
>
> #################################################################
> ###################################
> done
> Bytes transferred = 1510143 (170aff hex)
> ## Booting image at 00200000 ...
>
> Image Name: Linux-2.6.11.7
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1510079 Bytes = 1.4 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> setup_arch: enter
> setup_arch: bootmem
> ocp: exit
> arch: exit
>
>
>
>
>
> .....................
>
> Regards,
>
> Jianggan LI
>
> ________________________________
>
> From: John Rigby [mailto:jcrigby@gmail.com]
> Sent: Sat 2/25/2006 1:17
> To: #LI JIANGGAN#
> Cc: tnt@246tnt.com; linuxppc-embedded@ozlabs.org
>
> Subject: Re: boot failure on lite5200b board
>
>
>
>
> I don't think your syntax for appending to an env variable is correct:
>
> try:
> set bootargs $(bootargs) ...appended stuff...
> instead of:
> set bootargs env bootargs ...appended stuff....
>
> Also to see what bootargs is actually set to after all the nested
> commands, add a printenv just before the bootm
>
> On 2/23/06, #LI JIANGGAN# <lijianggan@pmail.ntu.edu.sg> wrote:
> >
> >
> > I have actually tried both kernel with both console configurations. It
> gave
> > the same output, thus I presume that the problem lies somewhere else. I
> > attached the log to this email.
> >
> > the board is Lite5200B Version 1.0. Which .config file do you want?
> >
> > Sylvain, we have ordered a debugging set but we are still waiting for
> > delivery, the leaking time is said to be one month, tant pis. And the log
> I
> > attached here are booting from a higher address (0x500000).
> >
> > My current u-boot args:
> > Autostarting. Press any key to abort..
> >
> > Hit any key to stop autoboot: 0
> > => printenv
> > baudrate=115200
> > autoload=no
> > ethact=FEC ETHERNET
> > flshroot=root=/dev/mtdblock2 rw
> > ethaddr=00:01:9F:00:27:2F
> > preboot=echo; echo Autostarting. Press any key to abort..; echo
> > bootdelay=5
> > hostname=icecube
> > bootfile=MPC5200/uImage
> > nv=nfsroot root=/dev/nfs rw nfsroot=10.190.3.113:/opt/eldk/rootfs
> > ip=ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
> > nfsroot=root=/dev/nfs rw
> nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> > bootcmd=run net_nfs
> > filesize=546
> > fileaddr=500000
> > netmask=255.255.240.0
> > ipaddr=10.190.3.144
> > serverip=10.190.3.103
> > setconsole=setenv bootargs console=ttyPSC0, 115200n8 console=tty1
> > rootfs=root=/dev/nfs rw
> nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> > bootargs=env bootargs root=/dev/nfs rw
> > nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> > ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
> > flash_nfs=run setconsole nfsargs addip;bootm
> > net_nfs=tftp 500000 MPC5200/uImage;run setconsole nfsargs addip;bootm
> > nfsargs=setenv bootargs env bootargs root=/dev/nfs rw
> > nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> >
> ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::offroot=/dev/nfs
> > rw
> > addip=setenv bootargs env bootargs root=/dev/nfs rw
> > nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> > ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
> > ramargs=setenv bootargs root=/dev/ram rw
> > console=console=ttyS0,115200n8 console=tty1
> > stdin=serial
> > stdout=serial
> > stderr=serial
> >
> > Environment size: 1472/65532 bytes
> > =>
> >
> >
> >
> >
> > USING Sylvain's KERNEL:
> >
> > U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
> >
> > CPU: MPC5200 v2.2 at 462 MHz
> > Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
> > Board: Freescale MPC5200 (Lite5200B)
> > I2C: 85 kHz, ready
> > DRAM: 256 MB
> > FLASH: 32 MB
> > PCI: Bus Dev VenId DevId Class Int
> > 00 1a 1057 5809 0680 00
> > In: serial
> > Out: serial
> > Err: serial
> > Net: FEC ETHERNET
> > IDE: Bus 0: OK
> > Device 0: not available
> > Device 1: not available
> >
> > Autostarting. Press any key to abort..
> >
> > Hit any key to stop autoboot: 0
> > Using FEC ETHERNET device
> > TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> > Filename 'MPC5200/uImage'.
> > Load address: 0x500000
> > Loading:
> #################################################################
> >
> ################################################################
> > done
> > Bytes transferred = 658114 (a0ac2 hex)
> > ## Booting image at 00500000 ...
> > Image Name: Linux-2.6.16-rc1
> > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > Data Size: 658050 Bytes = 642.6 kB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ... OK
> > id mach(): done
> > MMU:enter
> > MMU:hw init
> > MMU:mapin
> > MMU:setio
> > MMU:exit
> > setup_arch: enter
> > setup_arch: bootmem
> > arch: exit
> >
> >
> >
> > USING KERNEL FROM Freescale:
> >
> > U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
> >
> > CPU: MPC5200 v2.2 at 462 MHz
> > Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
> > Board: Freescale MPC5200 (Lite5200B)
> > I2C: 85 kHz, ready
> > DRAM: 256 MB
> > FLASH: 32 MB
> > PCI: Bus Dev VenId DevId Class Int
> > 00 1a 1057 5809 0680 00
> > In: serial
> > Out: serial
> > Err: serial
> > Net: FEC ETHERNET
> > IDE: Bus 0: OK
> > Device 0: not available
> > Device 1: not available
> >
> > Autostarting. Press any key to abort..
> >
> > Hit any key to stop autoboot: 0
> > Using FEC ETHERNET device
> > TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> > Filename 'MPC5200/uImage'.
> > Load address: 0x500000
> > Loading:
> #################################################################
> >
> #################################################################
> >
> #################################################################
> >
> #################################################################
> > ###################################
> > done
> > Bytes transferred = 1510143 (170aff hex)
> > ## Booting image at 00500000 ...
> > Image Name: Linux-2.6.11.7
> > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > Data Size: 1510079 Bytes = 1.4 MB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ... OK
> > id mach(): done
> > MMU:enter
> > MMU:hw init
> > MMU:mapin
> > MMU:setio
> > MMU:exit
> > setup_arch: enter
> > setup_arch: bootmem
> > ocp: exit
> > arch: exit
> >
> >
> >
> >
> > -----Original Message-----
> > From: John Rigby [mailto:jcrigby@gmail.com]
> > Sent: Fri 2/24/2006 0:18
> > To: #LI JIANGGAN#
> > Subject: Re: boot failure on lite5200b board
> >
> > If you are using Sylvain's kernel you need to set console=ttyPSC0. If
> you
> > are
> > using a kernel from Freescale then you need to set console=ttyS0.
> >
> > Also what rev of the board do you have?
> >
> >
> >
> > On 2/23/06, #LI JIANGGAN# <lijianggan@pmail.ntu.edu.sg> wrote:
> > >
> > >
> > > Thank you Jos? Mar?a and Andrey for your advices, however the problem
>
> > > remains. I've tried setting the console (though I remember that our
> > previous
> > > lite5200 board was working fine on kernel 2.4 without setting the
> > console);
> > > meantime, I've set the booting image to 0x500000; I have also tried
> using
> > > the kernel image come together with the BSP, it's always the same
> error.
> > >
> > > Sylvain, I've actually using your kernel source, the compiled image is
> > > around 700k (compared to the 1.4M image from the BSP), but it doesn't
> > solve
> > > the problem. So I presume that the problem is lying somewhere else.
> > >
> > > A SNAPSHOT OF THE BOOTING MESSAGES:
> > >
> > >
> > > U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
> > >
> > > CPU: MPC5200 v2.2 at 462 MHz
> > > Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
> > > Board: Freescale MPC5200 (Lite5200B)
> > > I2C: 85 kHz, ready
> > > DRAM: 256 MB
> > > FLASH: 32 MB
> > > PCI: Bus Dev VenId DevId Class Int
> > > 00 1a 1057 5809 0680 00
> > > In: serial
> > > Out: serial
> > > Err: serial
> > > Net: FEC ETHERNET
> > > IDE: Bus 0: OK
> > > Device 0: not available
> > > Device 1: not available
> > >
> > > Autostarting. Press any key to abort..
> > >
> > > Hit any key to stop autoboot: 0
> > > Using FEC ETHERNET device
> > > TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> > > Filename 'MPC5200/uImage'.
> > > Load address: 0x100000
> > > Loading:
> > >
> #################################################################
> > >
> > >
> ################################################################
> > > done
> > > Bytes transferred = 658114 (a0ac2 hex)
> > > ## Booting image at 00100000 ...
> > > Image Name: Linux-2.6.16-rc1
> > > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > > Data Size: 658050 Bytes = 642.6 kB
> > > Load Address: 00000000
> > > Entry Point: 00000000
> > > Verifying Checksum ... OK
> > > Uncompressing Kernel Image ... OK
> > > id mach(): done
> > > MMU:enter
> > > MMU:hw init
> > > MMU:mapin
> > > MMU:setio
> > > MMU:exit
> > > setup_arch: enter
> > > setup_arch: bootmem
> > > arch: exit
> > >
> > >
> > > I am wondering whether it's a kernel problem or more likely to be a
> > problem
> > > lying with the U-boot. It seems to hang when executing setup_arch()
> > > function, or maybe there is sth else behind the wall?
> > >
> > > Regards,
> > > Jianggan LI
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Sylvain Munaut [mailto:tnt@246tNt.com]
> > > Sent: Thu 2/23/2006 15:38
> > > To: #LI JIANGGAN#
> > > Cc: linuxppc-embedded@ozlabs.org
> > > Subject: Re: boot failure on lite5200b board
> > >
> > > #LI JIANGGAN# wrote:
> > > > Hello all,
> > > >
> > > > For my end-of-study project, I am working on an embedded system with
> > > > reference of freescale's lite5200b reference board. I was trying to
> > boot
> > > > Linux 2.6.15 on the board (with the fec and bestcomm corrected).
> > however
> > > > the booting was stuck at the following stage:
> > >
> > > In addition to what has already been said (use a higher address for
> the
> > > image and don't forget console=ttyPSC0 in kernel command line), make
> > > sure you use the kernel from my git tree, it contains a few patches
> from
> > > John Rigby to add support for the lite5200b.
> > >
> > > Please report if it works, I've not been able to test those myself
> since
> > > i'm still on lite5200.
> > >
> > >
> > > Sylvain
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
[-- Attachment #2: Type: text/html, Size: 32295 bytes --]
^ permalink raw reply
* Re: How to quickly write cleanmarkers to jffs2 partitions?
From: Mathieu Deschamps @ 2006-03-03 9:08 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200603021706.14618.david.jander@protonic.nl>
On Thursday 02 March 2006 17:06, David Jander wrote:
> Hi,
>
> I was wondering if there is a trick or common technique I am ignoring to
> make this more efficient:
>
> This is for a 2.4 kernel based system.
> In production we use either u-boot or a NFS mounted linux system to erase
> flash and write jffs2 partitions to it. The jffs2 images are small (not
> padded to full partition size to save programming time), but the partitions
> are rather big (12 Mbyte in one case). Problem is that when booting for the
> first time, one has to wait several minutes (during which the system is
> more or less useless and busy) to get all cleanmarkers written to flash by
> the jffs2 gc thread. This huge delay is rather unacceptable for production,
> so we are looking for a work-around.
>
> One option would be to make jffs2 images that are padded to full partition
> size, but that also isn't very efficient, considering the image is only
> about 100k in beginning and the partition is 12 Mbyte in size. That would
> take a lot of time programming flash (less time than having the jffs2
> driver fix this nevertheless).
>
> Another option is making a little program that writes cleanmarkers in every
> eraseblock starting from the first completely empty one in a partition
> before mounting that partition for the very first time after flashing.
>
> Since this seems to me like a common situation, I'd like to know if anybody
> knows about a better solution, or if anybody has already dealt with this
> before.
>
> Greetings,
Hi,
"When preparing a flash partition for JFFS2, it is recommended to put
cleanmarkers to the erased blocks.
This might be done my means of "-j" option of the "flash_eraseall" MTD
utility. Otherwise, JFFS2 will re-erase the blocks
which contain all 0xFF and have no cleanmarker. This is an unneeded wasting of
time."
Source : http://www.linux-mtd.infradead.org/faq/jffs2.html
does this may be relevant ?
Best Regards,
Mathieu Deschamps.
^ permalink raw reply
* Re: Linux on PPC
From: Adrian Cox @ 2006-03-03 9:33 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <4407CFD3.4060206@ovro.caltech.edu>
On Thu, 2006-03-02 at 21:10 -0800, David Hawkins wrote:
> Step 2. Find a PPC 750 port in the Linux source.
>
> For example, in the 2.6 series kernel, the place to start
> looking is under arch/ppc/platforms. grep -Ie 750 shows
> up some of the PPC 750 based systems.
>
> chestnut.c 750FX/GX evaluation board
> katana.c Looks like one too
> prpmc750.c Looks like a Motorola board
>
> Look at the comments in the code, look at the memory map
> of the reference board versus your custom board. There is
> a very good chance that the custom board is based on a
> reference design - thats the whole point of them.
I'd add the caution that within the 6xx, 7xx, and 7xxx family of
processors, the north-bridge makes a much greater difference than the
processor core. Within that family of processors Linux will auto-detect
the processor specific features at boot time. It will be easier to port
from a board using a 7450 with the same north-bridge, than from a board
using a 750 with a different north-bridge.
--
Adrian Cox <adrian@humboldt.co.uk>
^ permalink raw reply
* Re: incorrect rmo_top handling in prom_init
From: Olaf Hering @ 2006-03-03 11:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1141342541.13565.6.camel@localhost.localdomain>
On Fri, Mar 03, Benjamin Herrenschmidt wrote:
> On Thu, 2006-03-02 at 19:55 +0100, Olaf Hering wrote:
> > My iBook1 has 2 memory regions in reg. Depending on how I boot it
> > (vmlinux+initrd) or zImage.initrd, it will not boot with current Linus
> > tree.
> > rmo_top should be 160MB instead of 32MB.
>
> Does that fix it ?
My G5 may need similar tweaks. looking.
0 > dev /memory .properties
name memory
device_type memory
reg 00000000 00000000 10000000
00000000 00000000 00000000
00000000 00000000 00000000
00000000 00000000 00000000
00000000 00000000 00000000
00000000 00000000 00000000
00000000 00000000 00000000
00000000 00000000 00000000
slot-names 0000000f
DIMM0/J11
DIMM1/J12
DIMM2/J13
DIMM3/J14
available 00003000 0fbf9000
bank-names 0000000f
64 bit Bank0/J11/J12/front
64 bit Bank1/J11/J12/back
64 bit Bank2/J13/J14/front
64 bit Bank3/J13/J14/back
bank-sizes 10000000 00000000 00000000 00000000
dimm-info 8008070d 09014000 04607000 82100001 0e040c01 0220c075
70000048 30482a20 75754545 00000000 003c4830 2d550000
00000000 00000000 00000000 000000e7 ad000000 00000000
0148594d 44323136 20363436 41364a2d 4a202041 41033432
06873900 00000000 00000000 00000000 00000000 00000000
00000000 00000000 8008070d 09014000 04607000 82100001
0e040c01 0220c075 70000048 30482a20 75754545 00000000
003c4830 2d550000 00000000 00000000 00000000 000000e7
ad000000 00000000 0148594d 44323136 20363436 41364a2d
4a202041 41033432 06863800 00000000 00000000 00000000
00000000 00000000 00000000 00000000
... 00000200 bytes total
dimm-types DDR SDRAM
DDR SDRAM
dimm-speeds PC2700U-25330
PC2700U-25330
ram-layout-architecture 00000001
ok
^ permalink raw reply
* please pull powerpc-merge.git
From: Paul Mackerras @ 2006-03-03 11:23 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
More bugfixes, including a fix for the nasty timebase synchronization
bug reported by Kyle Moffett, plus a patch from Ben H. to tell
userland (via the AT_HWCAP mechanism) if the cpu has hardware threads
and if the i-cache snoops the d-cache.
Thanks,
Paul.
Benjamin Herrenschmidt:
powerpc: Fix old g5 issues with windfarm
powerpc: Fix windfarm_pm112 not starting all control loops
powerpc: Expose SMT and L1 icache snoop userland features
powerpc: incorrect rmo_top handling in prom_init
David Gibson:
powerpc: Fix incorrect pud_ERROR() message
Paul Mackerras:
powerpc: Fix might-sleep warning in program check exception handler
powerpc: Turn off verbose debug output in powermac platform functions
powerpc32: Fix timebase synchronization on 32-bit powermacs
arch/powerpc/kernel/cputable.c | 9 +++++--
arch/powerpc/kernel/prom_init.c | 2 +-
arch/powerpc/kernel/traps.c | 2 ++
arch/powerpc/platforms/powermac/pfunc_base.c | 5 ++++
arch/powerpc/platforms/powermac/pfunc_core.c | 6 +++++
arch/powerpc/platforms/powermac/smp.c | 2 +-
drivers/macintosh/windfarm_core.c | 7 ++++++
drivers/macintosh/windfarm_cpufreq_clamp.c | 8 +++++++
drivers/macintosh/windfarm_lm75_sensor.c | 32 +++++++++++++++++++-------
drivers/macintosh/windfarm_max6690_sensor.c | 25 +++++++++++++++-----
drivers/macintosh/windfarm_pm112.c | 8 ++++---
include/asm-powerpc/cputable.h | 2 ++
include/asm-powerpc/pgtable-4k.h | 2 +-
13 files changed, 85 insertions(+), 25 deletions(-)
^ permalink raw reply
* alignment bugs in prom_init
From: Olaf Hering @ 2006-03-03 13:57 UTC (permalink / raw)
To: linuxppc-dev
Some G5 and pSeries models dont boot with recent kernels. The reason is
likely the casting of pointers of stack variables to u32. One example is
the prom_getprop() call in prom_init_stdout().
sp is 0x0023e784, val is at offset 120, which makes 0x0023e7fc. This
address is casted to u32, which changes it to 0x0023e7f8. The firmware
writes to the wrong addres and things go downhill very quick.
c00000000040baa8: 3b 21 00 78 addi r25,r1,120
..
c00000000040baf4: 57 28 00 38 rlwinm r8,r25,0,0,28
..
c00000000040bb10: 4b ff d3 3d bl c000000000408e4c <.call_prom>
If I remove the casts and pass the pointer as is, everything starts to
work as expected? Why is all this (u32)(unsigned long) casting in
arch/powerpc/kernel/prom_init.c required?
Does -Os vs -O2 make a difference here?
^ permalink raw reply
* kmod: /sbin/modprobe char-major-4 failed
From: antonio.dibacco @ 2006-03-03 14:17 UTC (permalink / raw)
To: linuxppc-embedded
Why should the kernel try to load this char-major-4? What should I configure
in the kernel to have this module not loadable but included in the kernel?
Bye,
Antonio.
^ permalink raw reply
* Re: alignment bugs in prom_init
From: Andreas Schwab @ 2006-03-03 14:39 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060303135717.GA5707@suse.de>
Olaf Hering <olh@suse.de> writes:
> sp is 0x0023e784, val is at offset 120, which makes 0x0023e7fc. This
> address is casted to u32, which changes it to 0x0023e7f8.
Since when does casting to u32 cut off the low bits?
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: boot failure on lite5200b board
From: White @ 2006-03-03 15:01 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <84A109BF918D934CB46ACF33BCE187C002D54D96@mail02.student.main.ntu.edu.sg>
It looks like, your mpc52xx fec is missing...
have you patched in the FEC Driver ?
>Am Fri, 3 Mar 2006 16:06:40 +0800 schrieb "#LI JIANGGAN#"
><lijianggan@pmail.ntu.edu.sg> :
>I couldn't figure out why error 101 /* Network is unreachable */ is
>given. Below is my current U-boot settings and a snapshot of the
>booting:
^ permalink raw reply
* Re: alignment bugs in prom_init
From: Olaf Hering @ 2006-03-03 15:27 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jefylz1tkh.fsf@sykes.suse.de>
On Fri, Mar 03, Andreas Schwab wrote:
> Olaf Hering <olh@suse.de> writes:
>
> > sp is 0x0023e784, val is at offset 120, which makes 0x0023e7fc. This
> > address is casted to u32, which changes it to 0x0023e7f8.
>
> Since when does casting to u32 cut off the low bits?
Way before gcc4.0 release at least.
^ permalink raw reply
* Re: Linux on PPC
From: Wolfgang Denk @ 2006-03-03 16:00 UTC (permalink / raw)
To: nreddy; +Cc: linuxppc-embedded
In-Reply-To: <2611.61.95.208.2.1141362572.squirrel@61.95.208.2>
In message <2611.61.95.208.2.1141362572.squirrel@61.95.208.2> you wrote:
>
> 1. You can use u-boot as a boot loader.
> 2. You can choose any standard linux kernel but you may have to do some
> R&D on it to port to your board.
> Insted you can buy Montavista Linux, so that you can get support also.
Commercial support is available not only from MV, but also from many
other companies.
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
The one who says it cannot be done should never interrupt the one who
is doing it.
^ 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