* Fwd: Re: net/ieee80211/softmac/ieee80211softmac_io.c:464: warning: 'ieee80211softmac_send_ctl_frame' defined but not used
From: Toralf Förster @ 2006-05-23 12:45 UTC (permalink / raw)
To: linville; +Cc: netdev, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]
---------- Weitergeleitete Nachricht ----------
Subject: Re: net/ieee80211/softmac/ieee80211softmac_io.c:464:
warning: 'ieee80211softmac_send_ctl_frame' defined but not used
Date: Tuesday 23 May 2006 14:33
From: Johannes Berg <johannes@sipsolutions.net>
To: Toralf Förster <toralf.foerster@gmx.de>
Cc: linuxppc-dev@ozlabs.org
On Mon, 2006-05-22 at 19:48 +0200, Toralf Förster wrote:
> While playing with various kernel config I observed the warning above
> compiling 2.6.17-rc4-git10.
Yeah, known 'bug', we have that code there but never use it. Feel free
to submit a patch (to John Linville, CC netdev and softmac-dev) to
remove it.
johannes
-------------------------------------------------------
Here is a patch applicable fotr the current git kernel:
n22 ~ # cat patch_softmac
--- net/ieee80211/softmac/ieee80211softmac_io.c 2006-05-23 14:41:19.000000000
+0200
+++ net/ieee80211/softmac/ieee80211softmac_io.c_orig 2006-05-23
14:40:44.000000000 +0200
@@ -456,3 +456,31 @@
return IEEE80211_2ADDR_LEN;
}
+
+/* Sends a control packet */
+static int
+ieee80211softmac_send_ctl_frame(struct ieee80211softmac_device *mac,
+ struct ieee80211softmac_network *net, u32 type, u32 arg)
+{
+ void *pkt = NULL;
+ u32 pkt_size = 0;
+
+ switch(type) {
+ case IEEE80211_STYPE_RTS:
+ case IEEE80211_STYPE_CTS:
+ pkt_size = ieee80211softmac_rts_cts((struct
ieee80211_hdr_2addr **)(&pkt), mac, net, type);
+ break;
+ default:
+ printkl(KERN_DEBUG PFX "Unsupported Control Frame type: %i\n",
type);
+ return -EINVAL;
+ }
+
+ if(pkt_size == 0)
+ return -ENOMEM;
+
+ /* Send the packet to the ieee80211 layer for tx */
+ ieee80211_tx_frame(mac->ieee, (struct ieee80211_hdr *) pkt, pkt_size);
+
+ kfree(pkt);
+ return 0;
+}
--
MfG/Sincerely
Toralf Förster
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: net/ieee80211/softmac/ieee80211softmac_io.c:464: warning: 'ieee80211softmac_send_ctl_frame' defined but not used
From: Johannes Berg @ 2006-05-23 12:33 UTC (permalink / raw)
To: Toralf Förster; +Cc: linuxppc-dev
In-Reply-To: <200605221948.09538.toralf.foerster@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 330 bytes --]
On Mon, 2006-05-22 at 19:48 +0200, Toralf Förster wrote:
> While playing with various kernel config I observed the warning above
> compiling 2.6.17-rc4-git10.
Yeah, known 'bug', we have that code there but never use it. Feel free
to submit a patch (to John Linville, CC netdev and softmac-dev) to
remove it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-23 12:27 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <20060522221138.683790c2@diesel>
[-- Attachment #1: Type: text/plain, Size: 3046 bytes --]
On Mon, 2006-05-22 at 22:11 -0500, Hollis Blanchard wrote:
> The "auto-loading" stuff doesn't seem to be working for me on my
> PowerMac11,2, with a fresh git clone as of right now. What is the base
> module that should load all the others? After a "make install", I still
> had to modprobe almost everything by hand (`find ./snd-aoa -name \*.ko`
> in the source directory to get a list).
Odd. i2sbus should pull in all other required modules, and should itself
load automatically at boot due to having a modalias that matches the
of:... modalias the mac-io bus device for the i2s stuff has.
> snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is on it
> snd-aoa-codec-tas: created and attached tas instance
> snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is on it
> snd-aoa-codec-tas: created and attached tas instance
Uh. That one I need to check, there is no tas codec on your machine.
> snd: Unknown layout ID 0x44
That looks like you have snd-powermac loaded too. Or not? I don't think
I have anything that prints "snd:" as the prefix but I might be wrong.
> snd-aoa-fabric-layout: found bus with layout 68 (using)
> snd-aoa: fabric didn't like codec tas
> snd-aoa: fabric didn't like codec tas
> snd-aoa-codec-onyx: found pcm3052
> snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
> snd-aoa: fabric didn't like codec onyx
> snd-aoa-codec-onyx: created and attached onyx instance
> snd-aoa-codec-onyx: found pcm3052
> snd-aoa-fabric-layout: can use this codec
> snd-aoa-codec-onyx: attached to onyx codec via i2c
> snd-aoa-codec-onyx: created and attached onyx instance
Most of this is due to that device-tree bug on those machines.
> For the record, there are two "layout-id" properties in my device tree,
> as discussed in this patch:
> http://patchwork.ozlabs.org/linuxppc/patch?id=4867
Note that the patch is mine :)
But also note that this isn't the reason that there are two layout-id
properties, there really *are* two sound nodes with layout-id property
because there are two i2s busses for the two codecs.
> Ultimately, snd_aoa_codec_onyx seems to be the happy module. Only the
> headphone jack was enabled; I had to use GNOME's "Volume Control" panel
> applet to enable speakers or line out (both of which work).
>
> However, volume control doesn't work at all, for both line-out and
> headphone jacks. Should it?
Yes, it should. I think the bug is that the tas module thinks it can
attach a codec here. Can you try *not* loading that module and see if it
works better then? I'll try to see if I can make the tas module not
attach on those machines, but as long as you don't load it manually all
should be fine.
> Also, it would be helpful if the git tree were better publicized
> somewhere (e.g. http://johannes.sipsolutions.net/). I had to dig through a LOT of mails to find the source.
Sorry. I linked it up on http://johannes.sipsolutions.net/Projects/ and
will add a few more details later.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* [PATCH] make ams work with latest kernels
From: Johannes Berg @ 2006-05-23 11:32 UTC (permalink / raw)
To: Stelian Pop; +Cc: linuxppc-dev list, Linux Kernel list
For those who don't know: ams, written by Stelian Pop, is a driver for
the motion sensor present in some PowerBooks (the series the
PowerBook5,6 falls into, later ones have a slightly different one the
driver doesn't handle).
Even though we still don't seem to have a client that can actually use
this data (something to actually tell the hd to protect itself) I
updated the ams code to compile against the latest linux kernel
versions. I also fixed a buglet (the interrupt handler should return
IRQ_HANDLED even if the init flag isn't set yet since we own the
interrupts, they can't be shared).
Stelian and all, how about adding this driver to linux? hdaps seems to
be there even if it too doesn't serve a useful purpose at this time.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
--- ams-0.02.orig/ams.c 2006-05-22 15:24:51.545837212 +0200
+++ ams-0.02/ams.c 2006-05-22 15:36:10.175837212 +0200
@@ -97,7 +97,7 @@ struct ams {
int irq1; /* first irq line */
int irq2; /* second irq line */
struct work_struct worker; /* worker thread */
- struct input_dev idev; /* input device */
+ struct input_dev *idev; /* input device */
char iactive; /* is the input device active ? */
int xcalib; /* calibrated null value for x */
int ycalib; /* calibrated null value for y */
@@ -110,9 +110,10 @@ static int ams_attach(struct i2c_adapter
static int ams_detach(struct i2c_adapter *adapter);
static struct i2c_driver ams_driver = {
- .owner = THIS_MODULE,
- .name = "ams",
- .flags = I2C_DF_NOTIFY,
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = "ams",
+ },
.attach_adapter = ams_attach,
.detach_adapter = ams_detach,
};
@@ -210,10 +211,10 @@ static int ams_mouse_kthread(void *data)
while (!kthread_should_stop()) {
ams_sensors(&x, &y, &z);
- input_report_abs(&ams.idev, ABS_X, x - ams.xcalib);
- input_report_abs(&ams.idev, ABS_Y, y - ams.ycalib);
+ input_report_abs(ams.idev, ABS_X, x - ams.xcalib);
+ input_report_abs(ams.idev, ABS_Y, y - ams.ycalib);
- input_sync(&ams.idev);
+ input_sync(ams.idev);
msleep(25);
}
@@ -231,22 +232,24 @@ static void ams_mouse_enable(void)
ams.xcalib = x;
ams.ycalib = y;
- init_input_dev(&ams.idev);
- ams.idev.name = "ams";
- ams.idev.dev = &ams.client.dev;
-
- input_set_abs_params(&ams.idev, ABS_X, -50, 50, 3, 0);
- input_set_abs_params(&ams.idev, ABS_Y, -50, 50, 3, 0);
-
- set_bit(EV_ABS, ams.idev.evbit);
- set_bit(EV_KEY, ams.idev.evbit);
- set_bit(BTN_TOUCH, ams.idev.keybit);
+ ams.idev = input_allocate_device();
+ if (!ams.idev)
+ return;
+ ams.idev->name = "Apple Motion Sensor";
+ ams.idev->dev = &ams.client.dev;
+
+ input_set_abs_params(ams.idev, ABS_X, -50, 50, 3, 0);
+ input_set_abs_params(ams.idev, ABS_Y, -50, 50, 3, 0);
+
+ set_bit(EV_ABS, ams.idev->evbit);
+ set_bit(EV_KEY, ams.idev->evbit);
+ set_bit(BTN_TOUCH, ams.idev->keybit);
ams.kthread = kthread_run(ams_mouse_kthread, NULL, "kams");
if (IS_ERR(ams.kthread))
return;
- input_register_device(&ams.idev);
+ input_register_device(ams.idev);
ams.iactive = 1;
}
@@ -257,7 +260,8 @@ static void ams_mouse_disable(void)
kthread_stop(ams.kthread);
- input_unregister_device(&ams.idev);
+ if (ams.idev)
+ input_unregister_device(ams.idev);
ams.iactive = 0;
}
@@ -300,7 +304,7 @@ static void ams_worker(void *data)
static irqreturn_t ams_interrupt(int irq, void *devid, struct pt_regs *regs)
{
if (!ams.init)
- return IRQ_NONE;
+ return IRQ_HANDLED;
schedule_work(&ams.worker);
return IRQ_HANDLED;
}
@@ -471,7 +475,7 @@ static int __init ams_init(void)
INIT_WORK(&ams.worker, ams_worker, NULL);
- if ((ams.of_dev = of_platform_device_create(np, "ams")) == NULL) {
+ if ((ams.of_dev = of_platform_device_create(np, "ams", NULL)) == NULL) {
free_irq(ams.irq1, NULL);
free_irq(ams.irq2, NULL);
return -ENODEV;
^ permalink raw reply
* UART DRIVER on 2.6.15
From: Ladislav Klenovič @ 2006-05-23 12:02 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
just a simple question, is uart driver for kernel 2=2E6=2E15 complete=2E=
=20
There are some parts like:
void scc1_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC1: insert port configuration here */
pinfo->brg =3D 1;
}
=2E=2E=2E=2E
that seems to incomplete=2E Am I able to do something with SCC1 with th=
e current cpm_uart code?
Maybe stupid question, is there any way (is it possible) to import old =
uart driver from kernel 2=2E4=2Ex to kernel 2=2E6=2Ex
Regards,
Ladislav Klenovic
^ permalink raw reply
* Re: CRAMFS: Error -3 while decompressing!
From: Wolfgang Denk @ 2006-05-23 11:04 UTC (permalink / raw)
To: IGOR LURI; +Cc: linuxppc-embedded
In-Reply-To: <918EB199DDDFFA42BEA2EB3A1C6021F3D49640@correo.fagorautomation.net>
In message <918EB199DDDFFA42BEA2EB3A1C6021F3D49640@correo.fagorautomation.net> you wrote:
>
> We would want to use a Compact Flash card with VFAT file system to boot
> our system, so we need to store a linux kernel image and an initrd image
> on it.
Did you read http://www.denx.de/wiki/view/DULG/RootFileSystemInAReadOnlyFile ???
> U-Boot can load linux kernel image and initrd from Compact Flash to RAM.
No need to waste memory on a (big) ramdisk.
> We haven't choose already the initrd file system type, but CRAMFS is an
> option. However, as I mentioned in the previos message, a CRAMFS initrd
> doesn´t boot in our board.
cramfs makes no sense on a ramdisk image. Use ext2.
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
In theory, there is no difference between theory and practice. In
practice, however, there is.
^ permalink raw reply
* RE: CRAMFS: Error -3 while decompressing!
From: IGOR LURI @ 2006-05-23 10:15 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
>What's /dev/rw ???
Is a mistake, the correct argument is root=3D/dev/ram.
We would want to use a Compact Flash card with VFAT file system to boot =
our system, so we need to store a linux kernel image and an initrd image =
on it.
/boot/initrd.img
/boot/vmlinux.img
/custom/ (custom applications)
The contents of this initrd is basically busybox,libraris and device =
files:
/bin/busybox (and simbolik links to busybox) =09
/etc/*
/lib/lib*.so=20
/dev/*
/proc
/mnt/(here goes mounted Compact Flash card )
U-Boot can load linux kernel image and initrd from Compact Flash to RAM. =
Then, when linux boots, we can mount the Compact flash card and execute =
our custom applications.
We haven't choose already the initrd file system type, but CRAMFS is an =
option. However, as I mentioned in the previos message, a CRAMFS initrd =
doesn=B4t boot in our board.
Thanks in advance.
-----Mensaje original-----
De: wd@denx.de [mailto:wd@denx.de]
Enviado el: lunes, 22 de mayo de 2006 22:59
Para: IGOR LURI
CC: linuxppc-embedded@ozlabs.org
Asunto: Re: CRAMFS: Error -3 while decompressing!=20
In message <44718702.1070809@fagorautomation.es> you wrote:
>=20
> We have a mpc5200liteB evaluation board with u-boot 1.1.4 and linux=20
> 2.4.25 from Denx. We have grabed a cramfs root fs on a mtd partition =
> and we are able to boot linux without problems:
...
> However, we are not able to boot linux with the same rootfs image =
(with=20
> the u-boot header) loaded from RAM.
>=20
> setenv bootargs root=3D/dev/rw rw console=3DttyS0 =
console=3DttyS0
> init=3D/sbin/init ip=3Don
What's /dev/rw ???
> and CRAMFS image is built with correct endianess:
Ummm.. Why would you want to use a cramfs file system in a ramdisk
image? This iseems to be a truely pessimal combination of features to
me. Please see
http://www.denx.de/wiki/view/DULG/RootFileSystemDesignAndBuilding for
some hints...
Best regards,
Wolfgang Denk
--=20
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Life sucks, but it's better than the alternative."
- Peter da Silva
^ permalink raw reply
* RE: Setting I&D cache enable in the same mtspr instruction
From: Assaf Hoffman @ 2006-05-23 9:55 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Ronen Shitrit, Rita Shtern, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]
Attached.
Thanks.
-----Original Message-----
From: Mark A. Greer [mailto:mgreer@mvista.com]
Sent: Monday, May 15, 2006 10:00 PM
To: Assaf Hoffman
Cc: linuxppc-embedded@ozlabs.org; Rita Shtern; Ronen Shitrit
Subject: Re: Setting I&D cache enable in the same mtspr instruction
On Mon, May 08, 2006 at 01:39:13PM +0300, Assaf Hoffman wrote:
> Hi,
> I think the implementation of setup_common_caches() in file
> cpu_setup_6xx.S; not according to the spec as far as MPC74xx concerns.
> Looking in the spec (MPC7450 RISC Microprocessor Family Reference
> Manual, MPC7450UM Rev. 5 1/2005) section 3.4.1.5 L1 Instruction and
Data
> Cache Flash Invalidation it says:
> "Note that HID0[ICFI] and HID0[DCFI] must not both be set with the
same
> mtspr instruction, due to the synchronization requirements described
in
> Section 2.4.2.4.1, "Context Synchronization."
> But in the code those two do set together.
> Also, the same section says:
> "An isync must precede the setting of the HID0[ICFI] in order for the
> setting to take effect."
> But in the code, only 'sync' can be found.
>
> /* Enable caches for 603's, 604, 750 & 7400 */
> setup_common_caches:
> mfspr r11,SPRN_HID0
> andi. r0,r11,HID0_DCE
> ori r11,r11,HID0_ICE|HID0_DCE
> ori r8,r11,HID0_ICFI
> bne 1f /* don't invalidate the D-cache
> */
> ori r8,r8,HID0_DCI /* unless it wasn't enabled */
> 1: sync
> mtspr SPRN_HID0,r8 /* enable and invalidate caches
> */
> ^^^^^^^^^^^^^^^^^^^ Here we set both ICFI and DCFI in the same
> mtspr instruction. Also, no isync before setting ICFI.
> sync
> mtspr SPRN_HID0,r11 /* enable caches */
> sync
> isync
> blr
>
> Please advice.
> Thanks.
Yep, looks like a bug. How about a patch? :)
Mark
[-- Attachment #2: cpu_setup_6xx.S --]
[-- Type: application/octet-stream, Size: 10964 bytes --]
/*
* This file contains low level CPU setup functions.
* Copyright (C) 2003 Benjamin Herrenschmidt (benh@kernel.crashing.org)
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
*/
#include <linux/config.h>
#include <asm/processor.h>
#include <asm/page.h>
#include <asm/ppc_asm.h>
#include <asm/cputable.h>
#include <asm/ppc_asm.h>
#include <asm/offsets.h>
#include <asm/cache.h>
_GLOBAL(__setup_cpu_601)
blr
_GLOBAL(__setup_cpu_603)
b setup_common_caches
_GLOBAL(__setup_cpu_604)
mflr r4
bl setup_common_caches
bl setup_604_hid0
mtlr r4
blr
_GLOBAL(__setup_cpu_750)
mflr r4
bl __init_fpu_registers
bl setup_common_caches
bl setup_750_7400_hid0
mtlr r4
blr
_GLOBAL(__setup_cpu_750cx)
mflr r4
bl __init_fpu_registers
bl setup_common_caches
bl setup_750_7400_hid0
bl setup_750cx
mtlr r4
blr
_GLOBAL(__setup_cpu_750fx)
mflr r4
bl __init_fpu_registers
bl setup_common_caches
bl setup_750_7400_hid0
bl setup_750fx
mtlr r4
blr
_GLOBAL(__setup_cpu_7400)
mflr r4
bl __init_fpu_registers
bl setup_7400_workarounds
bl setup_common_caches
bl setup_750_7400_hid0
mtlr r4
blr
_GLOBAL(__setup_cpu_7410)
mflr r4
bl __init_fpu_registers
bl setup_7410_workarounds
bl setup_common_caches
bl setup_750_7400_hid0
li r3,0
mtspr SPRN_L2CR2,r3
mtlr r4
blr
_GLOBAL(__setup_cpu_745x)
mflr r4
#if defined(CONFIG_SMP) && defined(CONFIG_MARVELL)
/* this bits must be set for MP system - see 745x spec */
mfspr r6, HID1
oris r6, r6, 0x3000 // set : EBA and EBD
ori r6, r6, 0x0c00 // set : SyncBE and ABE
mtspr HID1, r6
sync
#endif
bl setup_common_caches
bl setup_745x_specifics
mtlr r4
blr
/* Enable caches for 603's, 604, 750 & 7400 */
setup_common_caches:
mfspr r11,SPRN_HID0
ori r8,r11,HID0_DCE
andi. r0,r11,HID0_DCE
bne 1f /* don't invalidate the D-cache */
ori r8,r8,HID0_DCI /* unless it wasn't enabled */
1: sync
mtspr SPRN_HID0,r8 /* enable and invalidate caches */
sync
ori r8,r11,HID0_ICE|HID0_DCE|HID0_ICFI
isync
sync
mtspr SPRN_HID0,r8 /* enable and invalidate Instruction cache */
sync
blr
/* 604, 604e, 604ev, ...
* Enable superscalar execution & branch history table
*/
setup_604_hid0:
mfspr r11,SPRN_HID0
ori r11,r11,HID0_SIED|HID0_BHTE
ori r8,r11,HID0_BTCD
sync
mtspr SPRN_HID0,r8 /* flush branch target address cache */
sync /* on 604e/604r */
mtspr SPRN_HID0,r11
sync
isync
blr
/* 7400 <= rev 2.7 and 7410 rev = 1.0 suffer from some
* erratas we work around here.
* Moto MPC710CE.pdf describes them, those are errata
* #3, #4 and #5
* Note that we assume the firmware didn't choose to
* apply other workarounds (there are other ones documented
* in the .pdf). It appear that Apple firmware only works
* around #3 and with the same fix we use. We may want to
* check if the CPU is using 60x bus mode in which case
* the workaround for errata #4 is useless. Also, we may
* want to explicitely clear HID0_NOPDST as this is not
* needed once we have applied workaround #5 (though it's
* not set by Apple's firmware at least).
*/
setup_7400_workarounds:
mfpvr r3
rlwinm r3,r3,0,20,31
cmpwi 0,r3,0x0207
ble 1f
blr
setup_7410_workarounds:
mfpvr r3
rlwinm r3,r3,0,20,31
cmpwi 0,r3,0x0100
bnelr
1:
mfspr r11,SPRN_MSSSR0
/* Errata #3: Set L1OPQ_SIZE to 0x10 */
rlwinm r11,r11,0,9,6
oris r11,r11,0x0100
/* Errata #4: Set L2MQ_SIZE to 1 (check for MPX mode first ?) */
oris r11,r11,0x0002
/* Errata #5: Set DRLT_SIZE to 0x01 */
rlwinm r11,r11,0,5,2
oris r11,r11,0x0800
sync
mtspr SPRN_MSSSR0,r11
sync
isync
blr
/* 740/750/7400/7410
* Enable Store Gathering (SGE), Address Brodcast (ABE),
* Branch History Table (BHTE), Branch Target ICache (BTIC)
* Dynamic Power Management (DPM), Speculative (SPD)
* Clear Instruction cache throttling (ICTC)
*/
setup_750_7400_hid0:
mfspr r11,SPRN_HID0
ori r11,r11,HID0_SGE | HID0_ABE | HID0_BHTE | HID0_BTIC
oris r11,r11,HID0_DPM@h
BEGIN_FTR_SECTION
xori r11,r11,HID0_BTIC
END_FTR_SECTION_IFSET(CPU_FTR_NO_BTIC)
BEGIN_FTR_SECTION
xoris r11,r11,HID0_DPM@h /* disable dynamic power mgmt */
END_FTR_SECTION_IFSET(CPU_FTR_NO_DPM)
li r3,HID0_SPD
andc r11,r11,r3 /* clear SPD: enable speculative */
li r3,0
mtspr SPRN_ICTC,r3 /* Instruction Cache Throttling off */
isync
mtspr SPRN_HID0,r11
sync
isync
blr
/* 750cx specific
* Looks like we have to disable NAP feature for some PLL settings...
* (waiting for confirmation)
*/
setup_750cx:
mfspr r10, SPRN_HID1
rlwinm r10,r10,4,28,31
cmpwi cr0,r10,7
cmpwi cr1,r10,9
cmpwi cr2,r10,11
cror 4*cr0+eq,4*cr0+eq,4*cr1+eq
cror 4*cr0+eq,4*cr0+eq,4*cr2+eq
bnelr
lwz r6,CPU_SPEC_FEATURES(r5)
li r7,CPU_FTR_CAN_NAP
andc r6,r6,r7
stw r6,CPU_SPEC_FEATURES(r5)
blr
/* 750fx specific
*/
setup_750fx:
blr
/* MPC 745x
* Enable Store Gathering (SGE), Branch Folding (FOLD)
* Branch History Table (BHTE), Branch Target ICache (BTIC)
* Dynamic Power Management (DPM), Speculative (SPD)
* Ensure our data cache instructions really operate.
* Timebase has to be running or we wouldn't have made it here,
* just ensure we don't disable it.
* Clear Instruction cache throttling (ICTC)
* Enable L2 HW prefetch
*/
setup_745x_specifics:
/* We check for the presence of an L3 cache setup by
* the firmware. If any, we disable NAP capability as
* it's known to be bogus on rev 2.1 and earlier
*/
mfspr r11,SPRN_L3CR
andis. r11,r11,L3CR_L3E@h
beq 1f
lwz r6,CPU_SPEC_FEATURES(r5)
andi. r0,r6,CPU_FTR_L3_DISABLE_NAP
beq 1f
li r7,CPU_FTR_CAN_NAP
andc r6,r6,r7
stw r6,CPU_SPEC_FEATURES(r5)
1:
mfspr r11,SPRN_HID0
/* All of the bits we have to set.....
*/
ori r11,r11,HID0_SGE | HID0_FOLD | HID0_BHTE
ori r11,r11,HID0_LRSTK | HID0_BTIC
oris r11,r11,HID0_DPM@h
BEGIN_FTR_SECTION
xori r11,r11,HID0_BTIC
END_FTR_SECTION_IFSET(CPU_FTR_NO_BTIC)
BEGIN_FTR_SECTION
xoris r11,r11,HID0_DPM@h /* disable dynamic power mgmt */
END_FTR_SECTION_IFSET(CPU_FTR_NO_DPM)
/* All of the bits we have to clear....
*/
li r3,HID0_SPD | HID0_NOPDST | HID0_NOPTI
andc r11,r11,r3 /* clear SPD: enable speculative */
li r3,0
mtspr SPRN_ICTC,r3 /* Instruction Cache Throttling off */
isync
mtspr SPRN_HID0,r11
sync
isync
/* Enable L2 HW prefetch
*/
mfspr r3,SPRN_MSSCR0
ori r3,r3,3
sync
mtspr SPRN_MSSCR0,r3
sync
isync
blr
/*
* Initialize the FPU registers. This is needed to work around an errata
* in some 750 cpus where using a not yet initialized FPU register after
* power on reset may hang the CPU
*/
_GLOBAL(__init_fpu_registers)
mfmsr r10
ori r11,r10,MSR_FP
mtmsr r11
isync
addis r9,r3,empty_zero_page@ha
addi r9,r9,empty_zero_page@l
REST_32FPRS(0,r9)
sync
mtmsr r10
isync
blr
/* Definitions for the table use to save CPU states */
#define CS_HID0 0
#define CS_HID1 4
#define CS_HID2 8
#define CS_MSSCR0 12
#define CS_MSSSR0 16
#define CS_ICTRL 20
#define CS_LDSTCR 24
#define CS_LDSTDB 28
#define CS_SIZE 32
.data
.balign L1_CACHE_LINE_SIZE
cpu_state_storage:
.space CS_SIZE
.balign L1_CACHE_LINE_SIZE,0
.text
/* Called in normal context to backup CPU 0 state. This
* does not include cache settings. This function is also
* called for machine sleep. This does not include the MMU
* setup, BATs, etc... but rather the "special" registers
* like HID0, HID1, MSSCR0, etc...
*/
_GLOBAL(__save_cpu_setup)
/* Some CR fields are volatile, we back it up all */
mfcr r7
/* Get storage ptr */
lis r5,cpu_state_storage@h
ori r5,r5,cpu_state_storage@l
/* Save HID0 (common to all CONFIG_6xx cpus) */
mfspr r3,SPRN_HID0
stw r3,CS_HID0(r5)
/* Now deal with CPU type dependent registers */
mfspr r3,SPRN_PVR
srwi r3,r3,16
cmplwi cr0,r3,0x8000 /* 7450 */
cmplwi cr1,r3,0x000c /* 7400 */
cmplwi cr2,r3,0x800c /* 7410 */
cmplwi cr3,r3,0x8001 /* 7455 */
cmplwi cr4,r3,0x8002 /* 7457 */
cmplwi cr5,r3,0x8003 /* 7447A */
cmplwi cr6,r3,0x7000 /* 750FX */
/* cr1 is 7400 || 7410 */
cror 4*cr1+eq,4*cr1+eq,4*cr2+eq
/* cr0 is 74xx */
cror 4*cr0+eq,4*cr0+eq,4*cr3+eq
cror 4*cr0+eq,4*cr0+eq,4*cr4+eq
cror 4*cr0+eq,4*cr0+eq,4*cr1+eq
cror 4*cr0+eq,4*cr0+eq,4*cr5+eq
bne 1f
/* Backup 74xx specific regs */
mfspr r4,SPRN_MSSCR0
stw r4,CS_MSSCR0(r5)
mfspr r4,SPRN_MSSSR0
stw r4,CS_MSSSR0(r5)
beq cr1,1f
/* Backup 745x specific registers */
mfspr r4,SPRN_HID1
stw r4,CS_HID1(r5)
mfspr r4,SPRN_ICTRL
stw r4,CS_ICTRL(r5)
mfspr r4,SPRN_LDSTCR
stw r4,CS_LDSTCR(r5)
mfspr r4,SPRN_LDSTDB
stw r4,CS_LDSTDB(r5)
1:
bne cr6,1f
/* Backup 750FX specific registers */
mfspr r4,SPRN_HID1
stw r4,CS_HID1(r5)
/* If rev 2.x, backup HID2 */
mfspr r3,SPRN_PVR
andi. r3,r3,0xff00
cmpwi cr0,r3,0x0200
bne 1f
mfspr r4,SPRN_HID2
stw r4,CS_HID2(r5)
1:
mtcr r7
blr
/* Called with no MMU context (typically MSR:IR/DR off) to
* restore CPU state as backed up by the previous
* function. This does not include cache setting
*/
_GLOBAL(__restore_cpu_setup)
/* Some CR fields are volatile, we back it up all */
mfcr r7
/* Get storage ptr */
lis r5,(cpu_state_storage-KERNELBASE)@h
ori r5,r5,cpu_state_storage@l
/* Restore HID0 */
lwz r3,CS_HID0(r5)
sync
isync
mtspr SPRN_HID0,r3
sync
isync
/* Now deal with CPU type dependent registers */
mfspr r3,SPRN_PVR
srwi r3,r3,16
cmplwi cr0,r3,0x8000 /* 7450 */
cmplwi cr1,r3,0x000c /* 7400 */
cmplwi cr2,r3,0x800c /* 7410 */
cmplwi cr3,r3,0x8001 /* 7455 */
cmplwi cr4,r3,0x8002 /* 7457 */
cmplwi cr5,r3,0x8003 /* 7447A */
cmplwi cr6,r3,0x7000 /* 750FX */
/* cr1 is 7400 || 7410 */
cror 4*cr1+eq,4*cr1+eq,4*cr2+eq
/* cr0 is 74xx */
cror 4*cr0+eq,4*cr0+eq,4*cr3+eq
cror 4*cr0+eq,4*cr0+eq,4*cr4+eq
cror 4*cr0+eq,4*cr0+eq,4*cr1+eq
cror 4*cr0+eq,4*cr0+eq,4*cr5+eq
bne 2f
/* Restore 74xx specific regs */
lwz r4,CS_MSSCR0(r5)
sync
mtspr SPRN_MSSCR0,r4
sync
isync
lwz r4,CS_MSSSR0(r5)
sync
mtspr SPRN_MSSSR0,r4
sync
isync
bne cr2,1f
/* Clear 7410 L2CR2 */
li r4,0
mtspr SPRN_L2CR2,r4
1: beq cr1,2f
/* Restore 745x specific registers */
lwz r4,CS_HID1(r5)
sync
mtspr SPRN_HID1,r4
isync
sync
lwz r4,CS_ICTRL(r5)
sync
mtspr SPRN_ICTRL,r4
isync
sync
lwz r4,CS_LDSTCR(r5)
sync
mtspr SPRN_LDSTCR,r4
isync
sync
lwz r4,CS_LDSTDB(r5)
sync
mtspr SPRN_LDSTDB,r4
isync
sync
2: bne cr6,1f
/* Restore 750FX specific registers
* that is restore HID2 on rev 2.x and PLL config & switch
* to PLL 0 on all
*/
/* If rev 2.x, restore HID2 with low voltage bit cleared */
mfspr r3,SPRN_PVR
andi. r3,r3,0xff00
cmpwi cr0,r3,0x0200
bne 4f
lwz r4,CS_HID2(r5)
rlwinm r4,r4,0,19,17
mtspr SPRN_HID2,r4
sync
4:
lwz r4,CS_HID1(r5)
rlwinm r5,r4,0,16,14
mtspr SPRN_HID1,r5
/* Wait for PLL to stabilize */
mftbl r5
3: mftbl r6
sub r6,r6,r5
cmplwi cr0,r6,10000
ble 3b
/* Setup final PLL */
mtspr SPRN_HID1,r4
1:
mtcr r7
blr
^ permalink raw reply
* question about linux with Xilinx ML-403
From: Ming Liu @ 2006-05-23 9:41 UTC (permalink / raw)
To: rick.moleres; +Cc: linuxppc-embedded
Hi Rick,
> Yes, we have a driver for the PLB TEMAC (different than the GSRD LL
> TEMAC) for Linux 2.4 (MontaVista Linux 2.4.20) that's shipped in EDK
> 8.1.1, and MontaVista is on the verge of publishing a driver for PLB
> TEMAC for Linux 2.6. (I believe it came across this mailing list a few
> weeks ago)
I have generated the BSP by EDK 8.1.1 for my project in ML403(hardcore
Temac and PLB Temac included). I noticed that there is a directory called
Xilinx_gige in the directory of /drivers/net. Is this the driver for
MontaVista Linux2.4.20? I copied the BSP and overwrote the original one in
the linux kernel directory (in the kernel directory, there is only a
directory called Xilinx_enet, no Xilinx_gige. So I just copied
Xilinx_gige.). However, my problem is in the menuconfig item of Network
Device Support->1000Mbit ethernet, there is not any option to choose and
enable the Xilinx on-chip ethernet. Is this a problem of MontaVista Linux
3.1 Preview Kit, or my problem? And What shall I do to enable the tri-mode
Temac in my platform? Thanks for your answer.
BR
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* question about linux with Xilinx ML-403
From: Ming Liu @ 2006-05-23 9:41 UTC (permalink / raw)
To: rick.moleres; +Cc: linuxppc-embedded
Hi Rick,
> Yes, we have a driver for the PLB TEMAC (different than the GSRD LL
> TEMAC) for Linux 2.4 (MontaVista Linux 2.4.20) that's shipped in EDK
> 8.1.1, and MontaVista is on the verge of publishing a driver for PLB
> TEMAC for Linux 2.6. (I believe it came across this mailing list a few
> weeks ago)
I have generated the BSP by EDK 8.1.1 for my project in ML403(hardcore
Temac and PLB Temac included). I noticed that there is a directory called
Xilinx_gige in the directory of /drivers/net. Is this the driver for
MontaVista Linux2.4.20? I copied the BSP and overwrote the original one in
the linux kernel directory (in the kernel directory, there is only a
directory called Xilinx_enet, no Xilinx_gige. So I just copied
Xilinx_gige.). However, my problem is in the menuconfig item of Network
Device Support->1000Mbit ethernet, there is not any option to choose and
enable the Xilinx on-chip ethernet. Is this a problem of MontaVista Linux
3.1 Preview Kit, or my problem? And What shall I do to enable the tri-mode
Temac in my platform? Thanks for your answer.
BR
Ming
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
^ permalink raw reply
* [PATCH] Add CMSPAR to termbits.h for powerpc and alpha
From: Paul Mackerras @ 2006-05-23 9:32 UTC (permalink / raw)
To: akpm; +Cc: linux-arch, linuxppc-dev
Some driver wants to use CMSPAR, but it was missing on alpha and
powerpc. This adds it, with the same value as every other
architecture uses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/include/asm-alpha/termbits.h b/include/asm-alpha/termbits.h
index f4837fa..5541101 100644
--- a/include/asm-alpha/termbits.h
+++ b/include/asm-alpha/termbits.h
@@ -148,6 +148,7 @@ #define PARODD 00020000
#define HUPCL 00040000
#define CLOCAL 00100000
+#define CMSPAR 010000000000 /* mark or space (stick) parity */
#define CRTSCTS 020000000000 /* flow control */
/* c_lflag bits */
diff --git a/include/asm-powerpc/termbits.h b/include/asm-powerpc/termbits.h
index ebf6055..6d533b0 100644
--- a/include/asm-powerpc/termbits.h
+++ b/include/asm-powerpc/termbits.h
@@ -153,6 +153,7 @@ #define PARODD 00020000
#define HUPCL 00040000
#define CLOCAL 00100000
+#define CMSPAR 010000000000 /* mark or space (stick) parity */
#define CRTSCTS 020000000000 /* flow control */
/* c_lflag bits */
^ permalink raw reply related
* Tri-mode or gigebit ethernet support problem in ML403
From: Ming Liu @ 2006-05-23 8:22 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-embedded
Hi Grant,
I want to ask you a problem about the 1000M ethernet support. Now I am
trying to integrate a linux (2.4 or 2.6) in my ML403 platform, with
tri-mode ethernet support. And I have downloaded many versions of linux,
including linuxppc_2_4_devel, MontaVista linux 3.1 Preview
Kit(v2.4.20_mvl31-ml300), and linux-xilinx-26. Unfortunately, I didn't find
any option in the menuconfig item Network Device Support->ethernet
(1000Mbit) for me to enable the 1000M ethernet in all three versions. So I
have the following questions to ask.
1. With Xilinx Virtex 4 tri-mode ethernet MAC support, which version of
Linux shall I use? I think I should choose a version with Xilinx On-chip
Ethernet supported in the 1000M ethernet item in menuconfig.
2. Assume that you can provide me a proper version. Shall I use Xilinx EDK
to generate the BSP for my platform and copy the source code to overwrite
the drivers in the original version. Then configure the kernel and enable
1000M ethernet (choose Xilinx on-chip ethernet). Then compile the
kernel...... Are these steps correct?
Thanks for your help. I am really confused about this problem. Also others
who can help me are welcome. :)
Best Regards
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* Re: HOW TO REPLY ON POST?
From: Daniel Ann @ 2006-05-23 8:11 UTC (permalink / raw)
To: Ladislav Klenovič; +Cc: linuxppc-embedded
In-Reply-To: <ea091fb452d44c86be254e3c0238a3a1@pobox.sk>
U2ltcGx5IGNsaWNrIG9uICJyZXBseSB0byBhbGwiIGJ1dHRvbiBpZiB5b3UgYXJlIG9uIEdVSS4g
T3RoZXJ3aXNlLAp5b3UgbWlnaHQgaGF2ZSB0byByZWFkIHVwIG9uIHlvdXIgbWFpbCB2aWV3ZXIg
Y29tbWFuZHMsIHdoaWNoIGRvZXMKc2ltaWxhci4KCk5vcm1hbGx5ICJyZXBseSIgb3IgInJlcGx5
IHRvIGFsbCIgd2lsbCBtYWludGFpbiB0aGUgb3JpZ2luYWwgc3ViamVjdApvZiB0aGUgZW1haWwg
eW91IGFyZSByZXBseWluZyB0by4gKE5vcm1hbGx5IHRoZXkgcHJlcGVuZCAiUkU6IikgQW5kCnRo
ZW4gaXRzIHVwIHRvIHRoZSBtYWlsaW5nIGxpc3QgZGFlbW9uIHRvIHNvcnQgaXQgaW4gb3V0IGJ5
IHRocmVhZC4KTWFnaWMgaGFwcGVucyBhdCB0aGUgbWFpbGluZyBsaXN0IGRhZW1vbiBpZiBhbGwg
Z29lcyB3ZWxsLgoKQ2hlZXJzLAoKT24gNS8yMy8wNiwgTGFkaXNsYXYgS2xlbm92aeggPGxrOTkz
MzZAcG9ib3guc2s+IHdyb3RlOgo+IEhpLAo+IHNvcnJ5IGZvciB0aGUgc3R1cGlkIHF1ZXN0aW9u
LCBidXQgaG93IHRvIHJlcGx5IG9uIHBvc3QgKGNvbnRpbnVlIGluIHRocmVhZCk/Cj4KPgo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gTGludXhwcGMt
ZW1iZWRkZWQgbWFpbGluZyBsaXN0Cj4gTGludXhwcGMtZW1iZWRkZWRAb3psYWJzLm9yZwo+IGh0
dHBzOi8vb3psYWJzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4cHBjLWVtYmVkZGVkCj4KCgot
LSAKRGFuaWVsCg==
^ permalink raw reply
* HOW TO REPLY ON POST?
From: Ladislav Klenovič @ 2006-05-23 7:23 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
sorry for the stupid question, but how to reply on post (continue in th=
read)?
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Hollis Blanchard @ 2006-05-23 3:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1147860564.14395.6.camel@johannes>
On Wed, 17 May 2006 12:09:24 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Currently snd-aoa is known to work on the following machines:
> * PowerBook5,8
> * PowerBook5,7
> * PowerMac8,1
> * PowerMac8,2
> * 17" October 2005 PowerBook (don't know the number)
> * PowerMac11,2
> * PowerBook6,8
> and my
> * PowerBook5,6
>
> People with those machines are encouraged to use and stress-test it,
> it also provides much better hardware support than snd-powermac, for
> example it can actually reprogram the hardware if you have a 48KHz
> file instead of having to digitally downsample it to 44.1KHz like
> required with snd-powermac in most cases.
The "auto-loading" stuff doesn't seem to be working for me on my
PowerMac11,2, with a fresh git clone as of right now. What is the base
module that should load all the others? After a "make install", I still
had to modprobe almost everything by hand (`find ./snd-aoa -name \*.ko`
in the source directory to get a list).
When the driver finally did completely load, I saw this in dmesg:
snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is on it
snd-aoa-codec-tas: created and attached tas instance
snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is on it
snd-aoa-codec-tas: created and attached tas instance
snd: Unknown layout ID 0x44
i2sbus: mapped i2s control registers
i2sbus: control register contents:
i2sbus: fcr0 = 0x8000056
i2sbus: cell_control = 0x5b43831a
i2sbus: fcr2 = 0xe7008000
i2sbus: fcr3 = 0x72009607
i2sbus: clock_control = 0x0
i2sbus: found i2s controller
snd-aoa-fabric-layout: found bus with layout 68 (using)
snd-aoa: fabric didn't like codec tas
snd-aoa: fabric didn't like codec tas
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
snd-aoa: fabric didn't like codec onyx
snd-aoa-codec-onyx: created and attached onyx instance
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: can use this codec
snd-aoa-codec-onyx: attached to onyx codec via i2c
snd-aoa-codec-onyx: created and attached onyx instance
serial format: 0x41190000
dws: 0x2000200
i2sbus: found i2s controller
snd-aoa-fabric-layout: found bus with layout 69 (using)
snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
snd-aoa: fabric didn't like codec onyx
snd-aoa: fabric didn't like codec tas
snd-aoa: fabric didn't like codec tas
serial format: 0x41100000
dws: 0x0
all codec info:
formats = 0x808
rates = 0x7fe
For the record, there are two "layout-id" properties in my device tree,
as discussed in this patch:
http://patchwork.ozlabs.org/linuxppc/patch?id=4867
Ultimately, snd_aoa_codec_onyx seems to be the happy module. Only the
headphone jack was enabled; I had to use GNOME's "Volume Control" panel
applet to enable speakers or line out (both of which work).
However, volume control doesn't work at all, for both line-out and
headphone jacks. Should it?
Also, it would be helpful if the git tree were better publicized
somewhere (e.g. http://johannes.sipsolutions.net/). I had to dig through a LOT of mails to find the source.
mkdir snd-aoa
cd snd-aoa/
git clone http://johannes.sipsolutions.net/snd-aoa.git/
cd snd-aoa/
make
-Hollis
P.S. Thanks for working on this Johannes!
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Tom Rini @ 2006-05-23 1:13 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060523005846.GA15797@mag.az.mvista.com>
On Mon, May 22, 2006 at 05:58:46PM -0700, Mark A. Greer wrote:
[snip]
> All of the boards would likely have to be of the same "class".
> Where "class" would be:
> 1) OF system
> 2) e300 core + PQIIPro (e.g., 83xx)
> 3) e500 core + PQIII (e.g., 85xx)
> 4) 6xx/7xx/74xx + mpc10x (e.g., sandpoint)
> etc. Something like that, anyway--maybe there are only "OF" and
> "non-OF'?
That's more limiting than we strictly need, I think. So long as we keep
the instructions that can't/aren't run-time nop'd over, or already done
in a way they don't run on the wrong core (ie ARCH=ppc and sandpoint
running fine on both 745x and 750), it should be (guessing a bit on the
64bit cpus):
1) 6xx/7xx/74xx/8xxx
2) 4xx
3) 8xx
4) 970
5) cell
6) etc
Or so. IOW, so long as we can either nop out, or possibly better yet,
have the compiler get things right (use Makefile/Kconfig magic to get
the LCD -mcpu=/-mtune= option so we run right). Things like PPC_BOARD1
and PPC_BOARD2 would then select PQIII core stuff, MPC10X core stuff,
TSI108 core stuff, GT64x60 core stuff, and so on. And maybe 8xxx has to
be split into BookE/non-BookE, at least to start with, for head*.S
reasons.
As a reminder to all, this also lets us say that if we just pick
PPC_8548CDS then only the stuff required for the 8548CDS would be
compiled into the kernel.
--
Tom Rini
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Mark A. Greer @ 2006-05-23 0:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1147930376.17679.72.camel@localhost.localdomain>
Thanks for your time, Ben. Sorry for taking so long to get back to you.
For the record, this patch was only a hack that I've done to get a sandpoint
up ASAP. I should have made it clear to not take Kconfig, etc. stuffs very
seriously. I was more worried about how we should fit flattened dt into the
bootwrapper.
I'm glad you did look at it so closely though and bring up a lot of good
questions. I'm not familiar with 64-bit platforms so all of my babbling
below is based on my 32-bit platform knowledge.
Mark
---
On Thu, May 18, 2006 at 03:32:55PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2006-05-17 at 17:21 -0700, Mark A. Greer wrote:
<snip>
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 6729c98..de09eac 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -323,7 +323,10 @@ config PPC_ISERIES
> >
> > config EMBEDDED6xx
> > bool "Embedded 6xx/7xx/7xxx-based board"
> > - depends on PPC32 && BROKEN
> > + depends on PPC32
> > + select PPC_UDBG_16550
> > + select MPIC
> > + select MPIC_SERIAL
>
> Not totally related to your patch but I'm tempted to turn that into a
> "Generic 6xx/7xx/7xxx" rather than "embedded" if we manage to always
> avoid board specific code most of the time, but instead add necessary
> bits in the device-tree. We still need a per-board Kconfig option I
> think that will just select the necessary bits and pieces (and more than
> one can be selected at one time). Also, I think right now, the embedded
> stuff is +/- exclusive from the MULTIPLATFORM stuff, that must be fixed
> asap. We are all living in the same kernel now :)
OK.
> > +
> > +config MPIC_SERIAL
> > + depends on EMBEDDED6xx
> > + bool
> > + default n
>
> Not sure what the above is, I'll have a look further in the patch but I
> can already tell you that it should be your per-board
> CONFIG_PPC_SANDPOINT for example that "selects" the various bits you
> need, and thus the above should depend on it, not EMBEDDED6xx... In fact
> I'm wondering wether we should kill EMBEDDED6xx :) Unless it's purely a
> reference to arch/powerpc/platforms/embedded6xx/ as a storage place for
> board setup_xxx.c files which is useful for platforms that really don't
> need more than one or 2 files in there.
I have no attachment to "embedded" so I'm happy to see it
go...especially if I correctly understand what you're saying below.
> > +ifeq ($(CONFIG_EMBEDDED6xx),y)
> > +src-boot += prom_embedded.c ns16550.c dts/sandpoint.S \
> > + dt_utils.c sandpoint.c mpc10x.c
> > +else
> > +src-boot += prom.c
> > +endif
>
> Again, I think CONFIG_EMBEDDED6xx is the wrong approach. I'd like to
> avoid the word "embedded" altogether anyway :) Thing is, it would be
> good if ultimately, embedded boards firmware was capable of passing a
> device-tree. Thus, embedded a device-tree in the zImage wrapper is more
> like a "fallback" solution which has the side effect of creating machine
> specific zImage's.
>
> That is why, I think, what we should do is have rules for building
> separate zImage wrappers. The basic OF one (which exists in both real
> and virtual mode versions and that I'd like to make capable of also
> working if a flat device-tree is passed in), the zImage.sandpoint, the
> zImage.prep, and whatever...
>
> Thus enabling CONFIG_PPC_MYBOARD should trigger the build of the
> board-flavored version of the wrapper in addition to all the other ones
> for the other boards built as part of a given config.
>
> I know it's a bit difficult because the current boot Kbuild rules aren't
> really design for multiple targets but I think that's the way to go.
Okay, to make sure I understand, you're saying that you want to support a
.config file having several CONFIG_PPC_BOARD1, CONFIG_PPC_BOARD2,
CONFIG_PPC_BOARD3 defined at the same time. The resulting zImage would
run on all 3 boards, right?
I'd be happy with that. It should meet the requirements of both
the multiplatform and embedded folks. You could combine that with the
tool paulus talked about a couple weeks ago which would tack the
appropriate flattened device tree (fdt) onto the zImage after the fact.
http://ozlabs.org/pipermail/linuxppc-dev/2006-April/022435.html
We just need to come up with the tool and make the bootwrapper code
smart enough to know what dt to use (an OF dt, an fdt from a firmware, a
fdt tacked on by the tool (along with code to take bd stuff & put it
into the fdt?)).
All of the boards would likely have to be of the same "class".
Where "class" would be:
1) OF system
2) e300 core + PQIIPro (e.g., 83xx)
3) e500 core + PQIII (e.g., 85xx)
4) 6xx/7xx/74xx + mpc10x (e.g., sandpoint)
etc. Something like that, anyway--maybe there are only "OF" and
"non-OF'?
Basically, if its not OF, then its classified by its core + bridge.
So, first thing the zImage does is look for an attached ftb (attached by
paulus' tool). If its there, use it. If its not there, use either the
OFDT (for OF class) or expect a dt to be passed in from the firmware (for
all the other classes). That way you can easily override the dt in the field.
> .../...
>
> About the .dts file, we should look into "shipping" a pre-built one so
> that dtc is not required for building a kernel.
Okay, paulus' tool would allow that. We should also make it smart
enough to replace an attached dts (really dtb--'b' for 'binary') with
a new one.
> I think we already have
> a mecanism for providing "shipped" versions of files and having the
> option of rebuilding them from source (though I don't have the details
> in mind at the moment)
I don't know what you're referring to here.
> > diff --git a/arch/powerpc/boot/io.h b/arch/powerpc/boot/io.h
>
> .../.. io stuffs ...
>
> Well... io accessors in here can't harm, the question is more how they
> are used ;)
>
> > +#define PCI_DEVFN(slot,func) ((((slot) & 0x1f) << 3) | ((func) & 0x07))
> > +
> > +/* Indirect PCI config space access routines */
> > +static inline void
> > +pci_indirect_read_config_byte(u32 *cfg_addr, u32 *cfg_data, int devfn,
> > + int offset, u8 *val)
> > +{
> > + out_be32(cfg_addr,
> > + ((offset & 0xfc) << 24) | (devfn << 16) | (0 << 8) | 0x80);
> > + *val = in_8((u8 *)(cfg_data + (offset & 3)));
> > + return;
> > +}
> > +
> > +static inline void
> > +pci_indirect_read_config_dword(u32 *cfg_addr, u32 *cfg_data, int devfn,
> > + int offset, u32 *val)
> > +{
> > + out_be32(cfg_addr,
> > + ((offset & 0xfc) << 24) | (devfn << 16) | (0 << 8) | 0x80);
> > + *val = in_le32(cfg_data + (offset & 3));
> > + return;
> > +}
>
> That's more annoying... if we start having PCI config space access in
> the boot wrapper how far will it stop ? I'd rather keep that sort of
> stuff local to myboard.c file unless it's really worth sharing... Unless
> we end up with really common need for them in which case those should be
> in separate files, possibly in a separate dir (thinking about it, prep
> will probably need that too)
Sure. I was just grabbing code I needed and sticking it whereever to
get things to work. If mpc10x.c is the only one that uses those routines
then they should be in that file only.
> The main problem is how do we do printf kind of things from such a
> bootloader. That needs IO, thus uart drivers etc... possibly parsing
> from the device-tree etc... I'm tempted to just have a global
> "boot_puts" function pointer set by the board and/or OF code to use
> through the bootloader, maybe a shared uart.c file with various uart
> bits and keep the gory implementation details of mapping the uart and
> using those uart bits in the myboard.c file...
Okay.
Question: are we still going to allow cmdline editing in the
bootwrapper? If so, we also need to get uart input and munge the dtb
to put the new args back into the /chosen/bootargs field.
> > +#ifdef CONFIG_PPC_OF
> > typedef void (*kernel_entry_t)( unsigned long,
> > unsigned long,
> > void *,
> > void *);
> > +#else
> > +void platform_fixups(void *dt_blob);
> > +extern void *dt_blob_start;
> > +extern void *dt_blob_end;
> > +void edit_cmdline(void *dt_blob_start);
> > +typedef void (*kernel_entry_t)(void *dtb_addr, void *kernel_entry_paddr,
> > + void *must_be_null);
> > +#endif
>
> Why 2 different prototypes for kernel_entry ?
One for "OF", one for "non-OF" but I'll change it to
"typedef void (*kernel_entry_t)(void *addr, ...);"
to support both. Hrm, I may have another idea... Anyway, I'll do
something about the #ifdef.
> I think we need something like CONFIG_PPC_BOOT_HAS_BUILTIN_DT that
> enables various DT related stuff in a clean way and have a builtin_dt.h
> file with related prototypes & definitions.
If we have the tool mentioned above, we shouldn't need a CONFIG option.
Just check for a NULL ptr or something like that which indicates there's
no dtb attached.
> > #undef DEBUG
> > @@ -218,7 +227,7 @@ void start(unsigned long a1, unsigned lo
> > if (getprop(chosen_handle, "stdout", &stdout, sizeof(stdout)) != 4)
> > exit();
> >
> > - printf("\n\rzImage starting: loaded at 0x%p (sp: 0x%p)\n\r", _start, sp);
> > + printf("\n\rzImage starting: loaded at 0x%p (sp: 0x%p)\n\r", _start,sp);
>
> Gratuituous uglyfication :)
Again, I was just hacking stuff...
<snip>
> >
> > /* Eventually gunzip the kernel */
> > @@ -299,6 +311,7 @@ #endif
> > flush_cache((void *)vmlinux.addr, vmlinux.size);
> >
> > kernel_entry = (kernel_entry_t)vmlinux.addr;
> > +#ifdef CONFIG_PPC_OF
> > #ifdef DEBUG
> > printf( "kernel:\n\r"
> > " entry addr = 0x%lx\n\r"
> > @@ -311,9 +324,20 @@ #ifdef DEBUG
> > #endif
>
> > kernel_entry(a1, a2, prom, NULL);
> > +#else /* !CONFIG_PPC_OF ==> flattened device tree */
> > +#ifdef DEBUG
> > + printf("kernel:\n\r"
> > + " entry addr = 0x%lx\n\r"
> > + " flattened dt = 0x%lx\n\r",
> > + (unsigned long)kernel_entry, &dt_blob_start);
> > +#endif
> > + edit_cmdline(&dt_blob_start);
> > + platform_fixups(&dt_blob_start);
> >
> > + kernel_entry(&dt_blob_start, (void *)vmlinux.addr, NULL);
> > +#endif
>
> Let's avoid #ifdef's if we can... provide function pointers where it
> matter setup by the board/OF init code maybe but not ifdef's. Afaik,
> only WD actually _likes_ ifdef's :)
I'll fix it up.
> > +++ b/arch/powerpc/boot/mpc10x.c
>
> We'll need some subdirs here or it will get messy quick...
Yep.
> > diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
>
> Same comment as above
>
> > +/* XXXX Get info from dt instead */
> > +static struct {
> > + int baud_base;
> > + unsigned long com_port;
> > + u16 iomem_reg_shift;
> > +} rs_table[RS_TABLE_SIZE] = {
> > + { BASE_BAUD, SANDPOINT_SERIAL_0, 0 },
> > + { BASE_BAUD, SANDPOINT_SERIAL_1, 0 },
> > +};
>
> Well, your own comment says it all :) I think we might need an
> equivalent of prom_parse.c in the bootloader
Yes, this was just a hack to get the sandpoint going.
> +
> > +/* #ifndef CONFIG_PPC_OF XXXX */
> > +
> > +/* Definitions used by the flattened device tree */
> > +#define OF_DT_HEADER 0xd00dfeed /* marker */
> > +#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
> > +#define OF_DT_END_NODE 0x2 /* End node */
> > +#define OF_DT_PROP 0x3 /* Property: name off, size,
> > + * content */
> > +#define OF_DT_NOP 0x4 /* nop */
> > +#define OF_DT_END 0x9
> > +
> > +#define OF_DT_VERSION 0x10
>
> .../... (flat DT definitions)
>
> Can't we share the kernel definition here ? Maybe split the kenrel one
> in two if necessary ? I don't like that sort of duplication...
I hope so. I'm hoping we can make a special dir somewhere that has the
definitions of stuff shared between the bootwrapper & the kernel.
How about arch/powerpc/shared? I dunno, something sensible.
> > +unsigned long serial_init(int chan, void *ignored);
> > +void serial_putc(unsigned long com_port, unsigned char c);
> > +unsigned char serial_getc(unsigned long com_port);
> > +int serial_tstc(unsigned long com_port);
>
> Forgot to mention that earlier, but those should be uart_* imho (or even
> 16550_*) since we'll surely have different species of serial ports to
> deal with and I don't like name mixup. Unless we consider that only ever
> one of those serial files get built in a given zImage wrapper in which
> case it makes some sense...
Okay.
> > +call_prom(const char *service, int nargs, int nret, ...)
> > +{
> > +
> > + static struct {
> > + char *service;
> > + int ((*rtn)(int nargs, int nret, va_list args));
> > + } services[] = {
> > + { "exit", service_exit },
> > + { "finddevice", service_finddevice },
> > + { "getprop", service_getprop },
> > + /* { "write", service_write }, */
> > + };
> > + va_list args;
> > + int i, rc = 0;
> > +
> > + for (i=0; i<ARRAY_SIZE(services); i++)
> > + if (!strcmp(service, services[i].service)) {
> > + va_start(args, nret);
> > + rc = services[i].rtn(nargs, nret, args);
> > + va_end(args);
> > + }
> > +
> > + return (nret > 0)? rc : 0;
> > +}
>
> I don't think call_prom is the right abstraction :) We have to decide
> here, we have two choices:
>
> - Either a given zImage wrapper can be booted from both a real OF and
> have an embedded flat DT, in which case we need function pointers and I
> think the right abstraction is for individual prom functions to have
> their function pointer rathaer than "multiplex" through call_prom
>
> - Or a given zImage wrapper is a single board thingy. That is it is
> either the OF wrapper _or_ it can contain an embedded DT. Probably
> easier that way and no need for funciton pointers nor mux at all... I
> tend to think that might be the right way to go at this point...
> Especially since as I wrote before, I'm tempted to think we should just
> in that case build multiple zImage wrappers. The only thing there is
> that if we go that route, I'd like the "OF" one to also be able to boot
> with a flat DT passed on entry to it so it will be useable as a generic
> zImage for firmwares that have a flat DT to pass to the kernel. The only
> "issue" with that is it might be difficult to have console output unless
> we do the putc function pointer thing I described earlier and have
> several "uart" impleentations with differnet names and enough
> device-tree parsing to be able to instanciate them (almost a copy of
> kernel's legacy serial stuff). Another option if we want console output
> is to add something to the DT header specifically for use by such early
> boot code that specifies a function that can be called back for
> displaying thing as long as a given memory range isn't overriden (the FW
> itself)
>
> Comments are welcome here, this is I think the most tricky point and
> where we need to make a decision...
I'm very happy to not use the 'call_prom' abstraction. :)
I guess I have the first one in mind. You have a zImage that runs on
1 to n different platforms. The zImage has to determine which DT to use
(OF DT, fdt from firmware, fdt attached by tool) and pick it apart to
find the I/O resources and serial driver to use. The CONFIG_<BOARD>'s
that are defined would determine the drivers that get built in to the zImage.
> > diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> > index 6e67b5b..2feca55 100644
> > --- a/arch/powerpc/kernel/legacy_serial.c
> > +++ b/arch/powerpc/kernel/legacy_serial.c
> > @@ -147,9 +147,11 @@ static int __init add_legacy_isa_port(st
> > if (reg == NULL)
> > return -1;
> >
> > +#if 0 /* XXXX */
> > /* Verify it's an IO port, we don't support anything else */
> > if (!(reg[0] & 0x00000001))
> > return -1;
> > +#endif
>
> Gack ? Care to explain ?
This 'if' always executed and threw me into the weeds. I didn't get
back to really figuring it out. This was a hack to get going.
> > +obj-$(CONFIG_EMBEDDED6xx) += embedded6xx/
>
> Hrmph.... (random noises)
? No, I needed that to get the build to go into platforms/embedded6xx.
Since platforms/embedded6xx was already there, I assumed that was where
I was to put things like the sandpoint. If/when we get rid of
"embedded", I'll move it to whereever it should go then.
> > +/*
> > + * Define all of the IRQ senses and polarities. Taken from the
> > + * Sandpoint X3 User's manual.
> > + */
> > +static u_char sandpoint_openpic_initsenses[] __initdata = {
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 0: SIOINT */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 1: XXXX FILL?? */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 2: PCI Slot 1 */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 3: PCI Slot 2 */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 4: PCI Slot 3 */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 5: PCI Slot 4 */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 6: XXXX FILL?? */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 7: XXXX FILL?? */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 8: IDE (INT C) */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 9: IDE (INT D) */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 10: */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 11: */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 12: */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 13: */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 14: */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 15: */
> > +};
>
> Of course you already know that this has to go into the device-tree :)
Yeah, I guess it should. I'll have to figure out how to do that.
> > +/*
> > + * Interrupt setup and service. Interrrupts on the Sandpoint come
> > + * from the four PCI slots plus the 8259 in the Winbond Super I/O (SIO).
> > + * The 8259 is cascaded from EPIC IRQ0, IRQ1-4 map to PCI slots 1-4,
> > + * IDE is on EPIC 7 and 8.
> > + */
> > +static void __init
> > +sandpoint_init_IRQ(void)
> > +{
> > + struct mpic *mpic;
> > + phys_addr_t openpic_paddr = 0xfc000000 + /* XXXX */
> > + MPC10X_EUMB_EPIC_OFFSET;
> > +
> > + /* This doesn't handle i2c, dma, i2o, or timer intrs right now XXXX */
> > + mpic = mpic_alloc(openpic_paddr, MPIC_PRIMARY,
> > + 16 /* XXXX otherwise num_sources used */ ,
> > + NUM_8259_INTERRUPTS,
> > + 0, /* was 16 */
> > + NR_IRQS - 4 /* XXXX */,
> > + sandpoint_openpic_initsenses,
> > + sizeof(sandpoint_openpic_initsenses), " EPIC ");
> > +
> > + BUG_ON(mpic == NULL); /* XXXX */
> > + mpic_assign_isu(mpic, 0, openpic_paddr + 0x10200);
> > + mpic_init(mpic);
> > + mpic_setup_cascade(NUM_8259_INTERRUPTS, i8259_irq_cascade, NULL);
> > + i8259_init(0xfef00000, 0); /* pci iack addr */
> > +}
>
> It would be really nice if we could define properties to put in the
> "mpic" node that defines the various attributes to pass to it and that
> sort of thing so that we can have a generic "mpic_init_IRQ" that walks
> all MPICs and instanciate & link them in cascade when necessary... Oh
> well, food for thought, no high priority there.
That would be great to have!
> > +/*
> > + * Freescale Sandpoint interrupt routing.
> > + */
> > +static inline int
> > +x3_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
> > +{
> > + static char pci_irq_table[][4] =
> > + /*
> > + * PCI IDSEL/INTPIN->INTLINE
> > + * A B C D
> > + */
> > + {
> > + { 16, 0, 0, 0 }, /* IDSEL 11 - i8259 on Winbond */
> > + { 0, 0, 0, 0 }, /* IDSEL 12 - unused */
> > + { 18, 21, 20, 19 }, /* IDSEL 13 - PCI slot 1 */
> > + { 19, 18, 21, 20 }, /* IDSEL 14 - PCI slot 2 */
> > + { 20, 19, 18, 21 }, /* IDSEL 15 - PCI slot 3 */
> > + { 21, 20, 19, 18 }, /* IDSEL 16 - PCI slot 4 */
> > + };
> > +
> > + const long min_idsel = 11, max_idsel = 16, irqs_per_slot = 4;
> > + return PCI_IRQ_TABLE_LOOKUP;
> > +}
>
> Of course you also know that the above has to go into the device-tree as
> well :)
Okay... :)
> > +static void __init
> > +sandpoint_setup_winbond_83553(struct pci_controller *hose)
> > +{
> > + int devfn;
> > +
> > + /*
> > + * Route IDE interrupts directly to the 8259's IRQ 14 & 15.
> > + * We can't route the IDE interrupt to PCI INTC# or INTD# because those
> > + * woule interfere with the PMC's INTC# and INTD# lines.
> > + */
> > + /*
> > + * Winbond Fcn 0
> > + */
> > + devfn = PCI_DEVFN(11,0);
> > +
> > + early_write_config_byte(hose,
> > + 0,
> > + devfn,
> > + 0x43, /* IDE Interrupt Routing Control */
> > + 0xef);
> > + early_write_config_word(hose,
> > + 0,
> > + devfn,
> > + 0x44, /* PCI Interrupt Routing Control */
> > + 0x0000);
> > +
> > + /* Want ISA memory cycles to be forwarded to PCI bus */
> > + early_write_config_byte(hose,
> > + 0,
> > + devfn,
> > + 0x48, /* ISA-to-PCI Addr Decoder Control */
> > + 0xf0);
> > +
> > + /* Enable Port 92. */
> > + early_write_config_byte(hose,
> > + 0,
> > + devfn,
> > + 0x4e, /* AT System Control Register */
> > + 0x06);
> > + /*
> > + * Winbond Fcn 1
> > + */
> > + devfn = PCI_DEVFN(11,1);
> > +
> > + /* Put IDE controller into native mode. */
> > + early_write_config_byte(hose,
> > + 0,
> > + devfn,
> > + 0x09, /* Programming interface Register */
> > + 0x8f);
> > +
> > + /* Init IRQ routing, enable both ports, disable fast 16 */
> > + early_write_config_dword(hose,
> > + 0,
> > + devfn,
> > + 0x40, /* IDE Control/Status Register */
> > + 0x00ff0011);
> > + return;
> > +}
>
> How much of the above could/should be done by the wrapper since it does
> config space access hacks ? My idea is that we might be able to remove
> pretty much _everything_ from this sandpoint.c file ... My dream would
> be to have a generic board support that matches a list of known boards
> for which no special code is needed, only the device-tree (and possibly
> the zImage wrapper).
That's a good dream. :)
> The main things preventing us from doing that at the moment is that we
> need to define enough standard nodes/properties to have the ability to
> the setup interrupt controller tree entirely from it, and the PCI host
> bridges as well. For the later, that means encoding enough of the bridge
> type and config access method to allow having a generic device-tree
> based piece of code that does what add_bridges() does in a generic way.
Yep.
> > +static int
> > +x3_exclude_device(u_char bus, u_char devfn)
> > +{
> > + if ((bus == 0) && (PCI_SLOT(devfn) == 0))
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > + else
> > + return PCIBIOS_SUCCESSFUL;
> > +}
>
> If we need to exclude devices in a generic way, we could define a
> specific exclude list property... or use what I think has already been
> defined by OF for indicating which slots should be probed :)
I'll try to do it through pci quirks, if I can. If not, then I agree.
> > +static int __init
> > +add_bridge(struct device_node *dev)
> > +{
> > + int len;
> > + struct pci_controller *hose;
> > + int *bus_range;
> > +
> > + printk("Adding PCI host bridge %s\n", dev->full_name);
> > +
> > + bus_range = (int *) get_property(dev, "bus-range", &len);
> > + if (bus_range == NULL || len < 2 * sizeof(int))
> > + printk(KERN_WARNING "Can't get bus-range for %s, assume"
> > + " bus 0\n", dev->full_name);
> > +
> > + hose = pcibios_alloc_controller();
> > + if (hose == NULL)
> > + return -ENOMEM;
> > + hose->first_busno = bus_range ? bus_range[0] : 0;
> > + hose->last_busno = bus_range ? bus_range[1] : 0xff;
> > + setup_indirect_pci(hose, 0xfec00000, 0xfee00000);
> > +
> > + /* Interpret the "ranges" property */
> > + /* This also maps the I/O region and sets isa_io/mem_base */
> > + pci_process_bridge_OF_ranges(hose, dev, 1);
> > +
> > + return 0;
> > +}
>
> See above comments.... Looks ok but how many boards will end up having
> very small variations of that same code and thus can we find a way to
> make that totally generic...
Many...
> > +u32 mag_dbg = 0;
> > +
> > +static void __init
> > +sandpoint_setup_arch(void)
> > +{
> > + loops_per_jiffy = 100000000 / HZ;
> > + isa_io_base = 0xfe000000;
> > + isa_mem_base = 0x80000000;
> > + pci_dram_offset = 0;
>
> The isa stuff should probably be deduced from the device-tree, the
> default LPJ too, probably not even useful anymore since we are using the
> timebase nowadays.
Okay.
> > +#ifdef CONFIG_BLK_DEV_INITRD
> > + if (initrd_start)
> > + ROOT_DEV = Root_RAM0;
> > + else
> > +#endif
> > +#ifdef CONFIG_ROOT_NFS
> > + ROOT_DEV = Root_NFS;
> > +#else
> > + ROOT_DEV = Root_HDA1;
> > +#endif
>
> Same comment as above, this is fairly generic and we could even imagine
> something like a linux,default-boot-device thing in the DT...
OK.
> > +#if 1 /* XXXX NEW */
> > + {
> > + struct device_node *np;
> > +
> > + mag_dbg = 1;
> > + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> > + add_bridge(np);
> > + mag_dbg = 0;
> > +
> > + ppc_md.pci_swizzle = common_swizzle;
> > + ppc_md.pci_map_irq = x3_map_irq;
> > + ppc_md.pci_exclude_device = x3_exclude_device; /* XXXX */
> > + }
> > +#endif
>
> The problem of IRQ mapping & swizzling will be solved real soon
> (hopefully early 2.6.18) so that we can completely rely on the
> device-tree without needing device_node's for every PCI device. Only P2P
> bridges that don't do standard swizzling (typically bridges soldered on
> the motherboard) will require device nodes. I'm working on it :)
>
> The idea is that the host bridge will need the standard interrupt-map &
> interrupt-map-mask which will indicate the interrupt mapping for every
> line of every slot/device in the standard way handled by OF (that
> already works). And I'll add code that will be able to handle PCI
> devices without a node by artificially building their "interrupts"
> property based on the interrupt pin config space entry and walking up
> the PCI tree, doing standard swizzling when encountering a P2P bridge
> until we hit something with a device-node in which case we hook our
> result to the interrupt-map of that device-node.
Cool. I'll keep an eye out for that.
> > + if (cpu_has_feature(CPU_FTR_SPEC7450))
> > + /* 745x is different. We only want to pass along enable. */
> > + _set_L2CR(L2CR_L2E);
> > + else if (cpu_has_feature(CPU_FTR_L2CR))
> > + /* All modules have 1MB of L2. We also assume that an
> > + * L2 divisor of 3 will work.
> > + */
> > + _set_L2CR(L2CR_L2E | L2CR_L2SIZ_1MB | L2CR_L2CLK_DIV3
> > + | L2CR_L2RAM_PIPE | L2CR_L2OH_1_0 | L2CR_L2DF);
>
> Keeping in mind my idea of having as much generic code as possible,
> whould we do the above in the boot wrapper or if not, should we provide
> some DT entries indicating that L2CR should be reset and to which
> values ?
I vote for a DT entry.
> > +#if 0
> > + /* Untested right now. */
> > + if (cpu_has_feature(CPU_FTR_L3CR)) {
> > + /* Magic value. */
> > + _set_L3CR(0x8f032000);
> > + }
> > +#endif
> > +}
>
> Same comment as above but for L3CR
DT entry. :)
> .../...
>
> > +/*
> > + * Fix IDE interrupts.
> > + */
> > +static int __init
> > +sandpoint_fix_winbond_83553(void)
> > +{
> > + /* Make some 8259 interrupt level sensitive */
> > + outb(0xe0, 0x4d0);
> > + outb(0xde, 0x4d1);
> > +
> > + return 0;
> > +}
> > +
> > +arch_initcall(sandpoint_fix_winbond_83553);
> > +
> > +/*
> > + * Initialize the ISA devices on the Nat'l PC87308VUL SuperIO chip.
> > + */
> > +static int __init
> > +sandpoint_setup_natl_87308(void)
> > +{
> > + u_char reg;
> > +
> > + /*
> > + * Enable all the devices on the Super I/O chip.
> > + */
> > + SANDPOINT_87308_SELECT_DEV(0x00); /* Select kbd logical device */
> > + SANDPOINT_87308_CFG_OUTB(0xf0, 0x00); /* Set KBC clock to 8 Mhz */
> > + SANDPOINT_87308_DEV_ENABLE(0x00); /* Enable keyboard */
> > + SANDPOINT_87308_DEV_ENABLE(0x01); /* Enable mouse */
> > + SANDPOINT_87308_DEV_ENABLE(0x02); /* Enable rtc */
> > + SANDPOINT_87308_DEV_ENABLE(0x03); /* Enable fdc (floppy) */
> > + SANDPOINT_87308_DEV_ENABLE(0x04); /* Enable parallel */
> > + SANDPOINT_87308_DEV_ENABLE(0x05); /* Enable UART 2 */
> > + SANDPOINT_87308_CFG_OUTB(0xf0, 0x82); /* Enable bank select regs */
> > + SANDPOINT_87308_DEV_ENABLE(0x06); /* Enable UART 1 */
> > + SANDPOINT_87308_CFG_OUTB(0xf0, 0x82); /* Enable bank select regs */
> > +
> > + /* Set up floppy in PS/2 mode */
> > + outb(0x09, SIO_CONFIG_RA);
> > + reg = inb(SIO_CONFIG_RD);
> > + reg = (reg & 0x3F) | 0x40;
> > + outb(reg, SIO_CONFIG_RD);
> > + outb(reg, SIO_CONFIG_RD); /* Have to write twice to change! */
> > +
> > + return 0;
> > +}
>
> Looks like zImage wrapper work to me... Unless we ever get booted by a
> firmware that both provides a flat DT and doesn't do the above....
>
> Ok, I'm not _ABSOLUTELY_ trying to remove the need for a myboar.c file
> here ... but it might be worth doing something generic enough so that
> it's either reduced to the strict minimum in many cases _or_ made
> completely unnecessary if we can...
OK
> > +arch_initcall(sandpoint_setup_natl_87308);
> > +
> > +static int __init
> > +sandpoint_request_io(void)
> > +{
> > + request_region(0x00,0x20,"dma1");
> > + request_region(0x20,0x20,"pic1");
> > + request_region(0x40,0x20,"timer");
> > + request_region(0x80,0x10,"dma page reg");
> > + request_region(0xa0,0x20,"pic2");
> > + request_region(0xc0,0x20,"dma2");
> > +
> > + return 0;
> > +}
>
> The above has to go... not sure yet what is the best way but it's just a
> pain... Could be made dependent on the OFDT too
OK
> > +arch_initcall(sandpoint_request_io);
> > +#endif
> > +
> > +static void __init
> > +sandpoint_map_io(void)
> > +{
> > + io_block_mapping(0xfe000000, 0xfe000000, 0x02000000, _PAGE_IO);
> > +}
>
> To kill absolutely. What is it there for ? At the very least, make
> io_block_mapping allocate virtual space as discussed earlier. I'd like
> to keep BATs for RAM anyway
It'll go away eventually.
> > +static void
> > +sandpoint_restart(char *cmd)
> > +{
> > + local_irq_disable();
> > +
> > + /* Set exception prefix high - to the firmware */
> > + _nmask_and_or_msr(0, MSR_IP);
> > +
> > + /* Reset system via Port 92 */
> > + outb(0x00, 0x92);
> > + outb(0x01, 0x92);
> > +
> > + for(;;); /* Spin until reset happens */
> > +}
>
> The above is fairly common. (Or variations of it). In the context of a
> "generic" board, we could imagine having a list of known "reboot
> methods" and have a DT node indicating which one to use...
Yep.
> > +static void
> > +sandpoint_power_off(void)
> > +{
> > + local_irq_disable();
> > + for(;;); /* No way to shut power off with software */
> > + /* NOTREACHED */
> > +}
>
> The above is _VERY_ commmon :) probably worth just not having a callback
> in ppc_md. at all...
>
> > +static void
> > +sandpoint_halt(void)
> > +{
> > + sandpoint_power_off();
> > + /* NOTREACHED */
> > +}
>
> Same comment as before.
I do see a couple in arch/ppc/platforms that do something different so
how about keeping ppc_md.power_off/_halt but making the above the default
(with only 1 implementation) which can be changed by board code?
> > +static void
> > +sandpoint_show_cpuinfo(struct seq_file *m)
> > +{
> > + seq_printf(m, "vendor\t\t: Freescale\n");
> > + seq_printf(m, "machine\t\t: Sandpoint\n");
> > +}
>
> Do we need that ? We could define standard DT properties that get
> printed in cpuinfo and have that in setup-common.c ...
That would be better.
> .../... (commented out IDE code)
>
> This is a windbond ? Can't it just be probed/detected using normal PCI
> probing ?
I have to revisit all of the IDE stuff in that file and figure out
what's really needed (if any). That's why I have it all '#if 0' right
now. I will get to it eventually.
> > +
> > +/*
> > + * Set BAT 3 to map 0xf8000000 to end of physical memory space 1-to-1.
> > + */
> > +static __inline__ void
> > +sandpoint_set_bat(void)
> > +{
> > + unsigned long bat3u, bat3l;
> > +
> > + __asm__ __volatile__(
> > + " lis %0,0xf800\n \
> > + ori %1,%0,0x002a\n \
> > + ori %0,%0,0x0ffe\n \
> > + mtspr 0x21e,%0\n \
> > + mtspr 0x21f,%1\n \
> > + isync\n \
> > + sync "
> > + : "=r" (bat3u), "=r" (bat3l));
> > +}
>
> WTF ?
It'll disappear. The sandpoint.c is copied from arch/ppc and hacked.
Its pretty old so there's lots of code that can probably be weeded out.
> > +TODC_ALLOC();
> > +
> > +static int __init
> > +sandpoint_probe(void)
> > +{
> > + return 1;
> > +}
>
> WTF (bis) ? :)
bis?
Its just a hack to get it going.
> > +define_machine(sandpoint) {
> > + .name = "Sandpoint",
> > + .probe = sandpoint_probe,
> > + .setup_arch = sandpoint_setup_arch,
> > + .setup_io_mappings = sandpoint_map_io,
> > + .init_IRQ = sandpoint_init_IRQ,
> > + .show_cpuinfo = sandpoint_show_cpuinfo,
> > + .get_irq = mpic_get_irq,
> > + .restart = sandpoint_restart,
> > + .power_off = sandpoint_power_off,
> > + .halt = sandpoint_halt,
> > + .calibrate_decr = generic_calibrate_decr,
> > + /*
> > + .progress = udbg_progress,
> > + */
> > +};
>
> So on the TODO list, replace as much as we can of the above with
> generic_* equivalents until nothing remains :)
Yep, that's the goal.
> > diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> > index 7dcdfcb..1badbec 100644
> > --- a/arch/powerpc/sysdev/mpic.c
> > +++ b/arch/powerpc/sysdev/mpic.c
> > @@ -629,6 +629,13 @@ #endif /* CONFIG_SMP */
> > mb();
> > }
> >
> > +#ifdef CONFIG_MPIC_SERIAL
> > + /* For serial interrupts & set clock ratio */
> > + mpic_write(mpic->gregs, MPIC_GREG_GLOBAL_CONF_1,
> > + mpic_read(mpic->gregs, MPIC_GREG_GLOBAL_CONF_1)
> > + | (1<<27) | (0x7<<28));
> > +#endif
>
> This should not be an #ifdef.... this should be an MPIC init flag passed
> when initializing it. (and if we do generic device-tree instanciation of
> PIC's, we could define standard properties to put in the MPIC node to
> enable those flags).
Okay, I'll move it into the dt.
> Keep up the good work ! :)
Heh.
> Cheers,
> Ben.
Thanks for the comments.
Mark
^ permalink raw reply
* Re: [PATCH] powerpc: Auto reserve of device tree blob
From: Jon Loeliger @ 2006-05-22 16:25 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <20060518220408.49C6567A44@ozlabs.org>
On Thu, 2006-05-18 at 17:03, Michael Neuling wrote:
> From: Jimi Xenidis <jimix@watson.ibm.com>
>
> A devtree compiler (dtc) generated devtree blob is "relocatable" and so
> does not contain a reserved_map entry for the blob itself. This means
> that if passed to Linux, Linux will not get lmb_reserve() the blob and
> it could be over. The following patch will explicitly reserve the
> "blob" as it was given to us and stops prom_init.c from creating a
> reserved mapping for the blob.
>
> NOTE: that the dtc/kexec should not generate the blob reservation entry.
> Although if they do, LMB reserver handles overlaps.
The current DTC does not issue the memory reservation request.
As discussed earlier, it is now relying on the kernel
to do a reservation for the itself. While I've not seen
it applied yet, I am assuming that Jimi's patch from 14 April
is what is needed here and will be applied. (Maybe it
just needs a "Signed-off" to make it happen. Dunno.)
Thanks,
jdl
^ permalink raw reply
* Re: Preferred way to configure MTD physical mapping and partitioning
From: David Woodhouse @ 2006-05-22 22:35 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200605221232.14880.laurent.pinchart@tbox.biz>
On Mon, 2006-05-22 at 12:32 +0200, Laurent Pinchart wrote:
> - adding a board specific "driver" in drivers/mtd/maps and handle all mapping
> manually
> - adding board specific MTD configuration in arch/ppc/platforms with calls to
> physmap_set_partitions() and physmap_configure()
> - adding board specific MTD configuration in arch/ppc/platforms with a call to
> physmap_set_partitions(), and using the CONFIG_MTD_PHYSMAP option with
> physical mapping values provided in the kernel configuration.
>
> Could anyone comment on the preferred approach ?
None of the above. The physmap driver in the MTD git tree already works
with a platform_device, instead of needing a call to physmap_configure()
or manual configuration at build time. Either register a
platform_device, or preferably extend it to use an of_device too.
--
dwmw2
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Tom Rini @ 2006-05-22 22:22 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <1147999765.8515.6.camel@localhost.localdomain>
On Fri, May 19, 2006 at 10:49:25AM +1000, Michael Ellerman wrote:
> On Thu, 2006-05-18 at 17:37 -0700, Mark A. Greer wrote:
> > On Thu, May 18, 2006 at 08:47:01AM -0500, Matthew McClintock wrote:
> > > On Wed, 2006-05-17 at 17:21 -0700, Mark A. Greer wrote:
> > > > +void *
> > > > +dt_find_prop_by_name(void *dt_blob, char *full_name, u32 *val_sizep)
> > >
> > > Is there a reason you are not using of_get_flat_dt_prop() instead of
> > > implementing your own version?
> >
> > Yes. One is in the kernel, one isn't. Or, are you asking why I didn't
> > just copy the kernel code? If so, I probably should have.
> >
> > Hrm, we almost need a library of code shared between the kernel &
> > the bootwrapper. Sort of illegal but it would save duplicating code
> > like the flat dt code.
> >
> > Comments?
>
> Yeah we do. And it's not illegal IMHO as two of our boot wrappers
> (prom_init and the iSeries one) are linked with the kernel anyway.
And on all architectures (practically) the zlib inflate code is shared
between kernel and bootstuff. So it's not unprecidented to do the ugly
define abstractions to let you easily share code as needed.
--
Tom Rini
^ permalink raw reply
* Re: Viable PPC platform?
From: David Woodhouse @ 2006-05-22 22:21 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060522221556.E60273526CA@atlas.denx.de>
On Tue, 2006-05-23 at 00:15 +0200, Wolfgang Denk wrote:
> But then, a 400 MHz Geode is a bit faster than a 50 MHz 8xx, probably
> not only in terms of CPU performance but also in terms of memory
> bandwidth.
It's actually NAND flash, and the bandwidth sucks (the flash controller
on the Geode companion chip is quite slow). We're getting about 3 MiB/s
from it, although we _ought_ to be able to get 3½. I'm playing with
JFFS2 some more before I go back to tweaking the NAND drivers though.
--
dwmw2
^ permalink raw reply
* Re: Viable PPC platform?
From: Wolfgang Denk @ 2006-05-22 22:15 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-embedded
In-Reply-To: <1148334674.10288.30.camel@shinybook.infradead.org>
In message <1148334674.10288.30.camel@shinybook.infradead.org> you wrote:
>
> Out of interest, how old is that JFFS2 test? If it's with the ancient
> code in the 2.4 kernel, you'll get a _lot_ of improvement by using the
> 2.6 kernel.
This was on a MPC860 system running a 2.4.25 kernel tree with a MTD
snapshot of Spring 2005.
> It looks like it took about 13 seconds to mount the onboard 8MiB flash.
> I can mount 512MiB of flash in 7.9 seconds with the current kernel, with
> a 400MHz AMD Geode.
The file system size was actually only 4 MiB.
But then, a 400 MHz Geode is a bit faster than a 50 MHz 8xx, probably
not only in terms of CPU performance but also in terms of memory
bandwidth.
> There's more work going on right now to reduce the memory usage too.
Fine, thanks!
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
Make it right before you make it faster.
^ permalink raw reply
* Re: Viable PPC platform?
From: David Woodhouse @ 2006-05-22 21:51 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060509223113.5715D353DB1@atlas.denx.de>
On Wed, 2006-05-10 at 00:31 +0200, Wolfgang Denk wrote:
> And if somebody wants to see facts and numbers, please see
> http://www.denx.de/wiki/view/DULG/RootFileSystemSelection
Out of interest, how old is that JFFS2 test? If it's with the ancient
code in the 2.4 kernel, you'll get a _lot_ of improvement by using the
2.6 kernel.
It looks like it took about 13 seconds to mount the onboard 8MiB flash.
I can mount 512MiB of flash in 7.9 seconds with the current kernel, with
a 400MHz AMD Geode.
There's more work going on right now to reduce the memory usage too.
--
dwmw2
^ permalink raw reply
* Re: SCC1 as serial console
From: a b @ 2006-05-22 21:07 UTC (permalink / raw)
To: linuxppc-embedded
experiment
__________
http://auto.sme.sk - Všetko o autách (novinky, testy, autosalón, autoškola, porovnaj si auto)
^ permalink raw reply
* Re: SCC1 as serial console
From: Ladislav Klenovi? @ 2006-05-22 21:21 UTC (permalink / raw)
To: Ladislav Klenovi?; +Cc: linuxppc-embedded@ozlabs.org
HOW TO REPLY ON POSTS ?????????????????????? !!!!!!!!!!!!!!!!!!!
>-----P?vodn? spr?va-----
>Od: Ladislav Klenovi? [mailto:lk99336@pobox=2Esk]
>Odoslan?: 22=2E m?ja 2006 13:33
>Komu: linuxppc-embedded@ozlabs=2Eorg
>Predmet: SCC1 as serial console
>
>
>Hi,
>can anybody help me to setup the SCC1 port as serial console on MPC860=
with kernel 2=2E6=2E15=2E4? I would like to use it as system console d=
uring the booting proccess=2E I can not get any output on serial consol=
e during booting proccess, I use uboot=2E
>
>thnx,
>regards ladislav
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs=2Eorg
>https://ozlabs=2Eorg/mailman/listinfo/linuxppc-embedded
^ 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