* moving from devfs to udev with 2.6 kernel on 8xx board?
From: Robert P. J. Day @ 2005-04-11 13:37 UTC (permalink / raw)
To: Embedded PPC Linux list
since i don't have enough anguish in my life, i thought i might take
today to see if i can migrate from devfs to udev on my 8xx board. at
the moment, with a 2.6.11.7 kernel, i have:
busybox-1.00
networking with the I2C/SPI/SMC1 patch installed
devfs
JFFS2 support in kernel (but no partition definition yet)
before i start reading up on udev, any guidance on whether this will
be straightforward, or will i want to slit my wrists by lunch time?
thanks.
rday
^ permalink raw reply
* Re: [PATCH 1/3] PPC440EP: IBM EMAC support for the Bamboo board
From: Gerhard Jaeger @ 2005-04-11 13:17 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1112808669.24673.304.camel@rhino.az.mvista.com>
On Wednesday 06 April 2005 19:31, Wade Farnsworth wrote:
> This adds support for the Bamboo board in the EMAC driver.
>
> Jason McMullan pointed out to me that for the Bamboo Rev. 0 to boot from
> ethernet, the ANEG pin on SW2 needs to be turned off. If we use this,
> we can avoid using the PVR to determine which board rev, we're running
> on. This patch addresses this.
>
> Comments would be appreciated.
>
> -Wade Farnsworth
>
> Signed-off by: Wade Farnsworth <wfarnsworth@mvista.com>
>
Hi Wade,
reading your patch, I think there's a small bug! Please see my patch
below. First part is for fixing a nasty warning and the second addresses
the mentioned bug.
Cheers,
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
--- linux/drivers/net/ibm_emac/ibm_emac_phy.c.orig 2005-04-11 15:02:43.000000000 +0200
+++ linux/drivers/net/ibm_emac/ibm_emac_phy.c 2005-04-11 15:01:44.000000000 +0200
@@ -25,6 +25,7 @@
#include <linux/ethtool.h>
#include <linux/delay.h>
#include <linux/vmalloc.h>
+#include <asm/io.h>
#include "ibm_emac_phy.h"
@@ -90,7 +91,7 @@ static int ac104_init(struct mii_phy *ph
u8 *config2_addr, config2_val;
config2_addr = ioremap64(BAMBOO_FPGA_CONFIG2_REG_ADDR, 0x8);
config2_val = * config2_addr;
- iounmap(*config2_addr);
+ iounmap(config2_addr);
if (BAMBOO_AUTONEGOTIATE(config2_val))
return 0;
phy->def->features = SUPPORTED_TP | SUPPORTED_MII;
^ permalink raw reply
* 824x Sandpoint with 2.6.x
From: Sam Song @ 2005-04-11 9:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'd like to know where I could get a good start on
824x Sandpoint board with 2.6.x? Is linuxppc-2.5 BK
tree nice for me to work?
Thanks in advance,
Sam
_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/
^ permalink raw reply
* [PATCH] RE: FCC Ethernet startup crash
From: Stefan Nickl @ 2005-04-11 9:19 UTC (permalink / raw)
To: Rune Torgersen; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859345@ismail.innsys.innovsys.com>
[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]
On Fri, 2005-04-08 at 09:39 -0500, Rune Torgersen wrote:
> I'm not sure what is going on, but that patch causes me to get "eth0: tx
> queue full!." messages as soon as I try to use the ethernet
> (Same thing happened if I just tried to remove the fcc_restart from
> init_fcc_startup)
Well ...
I don't like to make up theories I can't test but I guess what's going
on is this: fcc_restart() does two things, it sets up the transmit
machinery by calling fcc_stop() (fep->tx_free = TX_RING_SIZE;), and it
actually turns on the FCC.
I'm not a network driver guru but from what we've seen I'd say when the
driver calls netif_start_queue(), it
1) must already be prepared to xmit
2) must not call fcc_enet_rx() before
So fcc_restart() needed to be split up because calling it before
netif_start_queue() has the risk of rx'ing a packet too early, and
calling it afterwards is too late for the tx side.
Maybe it'd already help to add "fep->tx_free = TX_RING_SIZE;" to the
tx_bd init in init_fcc_param()...
But regarding my current indisposition with hardware, I'd suggest to
choose the smaller of the two evils, that is calling fcc_restart()
before starting the queue, leaving but a tiny race condition on rx side.
Signed-off-by: Stefan Nickl <Stefan.Nickl@kontron.com>
--
Stefan Nickl
Kontron Modular Computers
[-- Attachment #2: fcc_enet_startup_crash_v3.patch --]
[-- Type: text/x-patch, Size: 1828 bytes --]
--- linux-2.5/arch/ppc/8260_io/fcc_enet.c.bak 2005-04-08 09:37:40.000000000 +0200
+++ linux-2.5/arch/ppc/8260_io/fcc_enet.c 2005-04-11 11:02:30.000000000 +0200
@@ -2158,16 +2158,6 @@ init_fcc_startup(fcc_info_t *fip, struct
*(volatile uint *)(BCSR_ADDR + 12) &= ~BCSR3_FETHIEN2;
*(volatile uint *)(BCSR_ADDR + 12) |= BCSR3_FETH2_RST;
#endif
-
-#if defined(CONFIG_USE_MDIO) || defined(CONFIG_TQM8260)
- /* start in full duplex mode, and negotiate speed
- */
- fcc_restart (dev, 1);
-#else
- /* start in half duplex mode
- */
- fcc_restart (dev, 0);
-#endif
}
#ifdef CONFIG_USE_MDIO
@@ -2372,24 +2362,28 @@ fcc_enet_open(struct net_device *dev)
fep->sequence_done = 0;
fep->link = 0;
- if (fep->phy) {
- fcc_restart(dev, 0); /* always start in half-duplex */
- mii_do_cmd(dev, fep->phy->ack_int);
- mii_do_cmd(dev, fep->phy->config);
- mii_do_cmd(dev, phy_cmd_config); /* display configuration */
- while(!fep->sequence_done)
- schedule();
-
- mii_do_cmd(dev, fep->phy->startup);
- netif_start_queue(dev);
- return 0; /* Success */
- }
- return -ENODEV; /* No PHY we understand */
+ if (!fep->phy)
+ return -ENODEV; /* No PHY we understand */
+
+ mii_do_cmd(dev, fep->phy->ack_int);
+ mii_do_cmd(dev, fep->phy->config);
+ mii_do_cmd(dev, phy_cmd_config); /* display configuration */
+ while(!fep->sequence_done)
+ schedule();
+
+ mii_do_cmd(dev, fep->phy->startup);
#else
fep->link = 1;
- fcc_restart(dev, 0); /* always start in half-duplex */
- netif_start_queue(dev);
- return 0; /* Always succeed */
#endif /* CONFIG_USE_MDIO */
+
+#if defined(CONFIG_USE_MDIO) || defined(CONFIG_TQM8260)
+ fcc_restart (dev, 1); /* start in full duplex mode */
+#else
+ fcc_restart (dev, 0); /* start in half duplex mode */
+#endif
+
+ netif_start_queue(dev);
+
+ return 0; /* Always succeed */
}
^ permalink raw reply
* Re: [PATCH] pmac: Improve sleep code of tumbler driver
From: Colin Leroy @ 2005-04-11 8:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113208474.8933.12.camel@gaston>
On Mon, 11 Apr 2005 18:34:34 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Mon, 2005-04-11 at 10:18 +0200, Colin Leroy wrote:
> > On Mon, 11 Apr 2005 12:00:54 +1000
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > This patch (applies on top of my previous one adding support for
> > > newer machines) improves the behaviour of the "tumbler/snapper"
> > > driver used on newer PowerMacs during sleep. It properly set the
> > > HW mutes to shut down amplifiers and does an analog shutdown of
> > > the codec. That might improve power consumption during sleep on a
> > > number of machines.
> >
> > I suppose it also fixes the occasionnal loud static noise that
> > sometimes at wakeup, for example on iBook G4s. Good :)
>
> I don't know, tell me. I didn't know about this problem.
It was reported here:
http://lists.debian.org/debian-powerpc/2005/01/msg00781.html
I didn't personnaly report it because it was hard to track it down;
it'd happen about once in twenty resumes (more often when you're in a
quiet place with strangers around, evidently, according to Murphy's
law), and nothing unusual appeared in dmesg (even with SND_DEBUG, which
doesn't debug much on ppc anyway). I just got used to mute the ibook
before sending it to sleep.
> > Btw, do you know where patches land in this time of SCM change, when
> > it's not in -mm ?
>
> -mm :) Linus didn't restart merging things yet.
Ok, thanks.
--
Colin
^ permalink raw reply
* Re: [PATCH] pmac: Improve sleep code of tumbler driver
From: Benjamin Herrenschmidt @ 2005-04-11 8:34 UTC (permalink / raw)
To: Colin Leroy; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <20050411101853.7f0e9385@colin.toulouse>
On Mon, 2005-04-11 at 10:18 +0200, Colin Leroy wrote:
> On Mon, 11 Apr 2005 12:00:54 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > This patch (applies on top of my previous one adding support for newer
> > machines) improves the behaviour of the "tumbler/snapper" driver used
> > on newer PowerMacs during sleep. It properly set the HW mutes to shut
> > down amplifiers and does an analog shutdown of the codec. That might
> > improve power consumption during sleep on a number of machines.
>
> I suppose it also fixes the occasionnal loud static noise that
> sometimes at wakeup, for example on iBook G4s. Good :)
I don't know, tell me. I didn't know about this problem.
> Btw, do you know where patches land in this time of SCM change, when
> it's not in -mm ?
-mm :) Linus didn't restart merging things yet.
Ben.
^ permalink raw reply
* Re: [PATCH] pmac: Improve sleep code of tumbler driver
From: Colin Leroy @ 2005-04-11 8:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, Takashi Iwai, debian-powerpc@lists.debian.org,
linuxppc-dev list
In-Reply-To: <1113184854.9567.522.camel@gaston>
On Mon, 11 Apr 2005 12:00:54 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> This patch (applies on top of my previous one adding support for newer
> machines) improves the behaviour of the "tumbler/snapper" driver used
> on newer PowerMacs during sleep. It properly set the HW mutes to shut
> down amplifiers and does an analog shutdown of the codec. That might
> improve power consumption during sleep on a number of machines.
I suppose it also fixes the occasionnal loud static noise that
sometimes at wakeup, for example on iBook G4s. Good :)
Btw, do you know where patches land in this time of SCM change, when
it's not in -mm ?
Thanks,
--
Colin
^ permalink raw reply
* Ethernet on Linux for MPC8250
From: gqbenjamin @ 2005-04-11 7:31 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: gqben
hi,
i use *SmartBits* to test the Ethernet rate of mpc8250, kernel is linux-2.4.20 with CONFIG_FCC_LXT971 and CONFIG_USE_MDIO.
if *SmartBits*'s rate set too high, for example 100 Mbps Full Duplex, each packet is 1514 Bytes, the kernel print '... Memory squeeze, dropping packet.' on uart.
later, stop *smartbits* and *cat /proc/meminfo*, the *MemFree* become small, try again, become smaller, look like the allocated memory do not be free.
finally the kernel break down, because all memory have been used.
Q. how can i do to let kernel do not break down? this problem is kernel's promblem?
i use linux-2.6.5 for mpc8250 to test, and get the same result.
have a nice day.
----------------------------------------------
21CNÓÊÏäÈ«ÃæÉýG
http://mail.21cn.com/huodong/0504/mail/
²ÊÆÁÊÖ»ú°×ËÍÀ²!¸Ï¿ìÀ´ÄÃ!
http://qipai.g.21cn.com
Öǻ۴óÌôÕ½¾ÍÔڵͼ۶ᱦ
http://super.21cn.com/
ÌåÑéÁíÀàÔ¼»á£¬¸ÐÊܱðÑùÀËÂþ
http://y.21cn.com/club/
СÁéͨ¶ÌÐÅÖÐÐÄ£¬¶ÌÐÅ÷ÈÁ¦ÎÞ¼«
http://pas.21cn.com/
È«ÄÜÁÄ2005°æÉÁÁÁµÇ³¡£¡
http://callme.21cn.com
----------------------------------------------
21CNÓÊÏäÈ«ÃæÉýG
http://mail.21cn.com/huodong/0504/mail/
²ÊÆÁÊÖ»ú°×ËÍÀ²!¸Ï¿ìÀ´ÄÃ!
http://qipai.g.21cn.com
Öǻ۴óÌôÕ½¾ÍÔڵͼ۶ᱦ
http://super.21cn.com/
ÌåÑéÁíÀàÔ¼»á£¬¸ÐÊܱðÑùÀËÂþ
http://y.21cn.com/club/
СÁéͨ¶ÌÐÅÖÐÐÄ£¬¶ÌÐÅ÷ÈÁ¦ÎÞ¼«
http://pas.21cn.com/
È«ÄÜÁÄ2005°æÉÁÁÁµÇ³¡£¡
http://callme.21cn.com
^ permalink raw reply
* Re: 2.6.x with TQM860L
From: Wolfgang Denk @ 2005-04-11 7:24 UTC (permalink / raw)
To: karim; +Cc: linuxppc-embedded
In-Reply-To: <4259FA09.8040508@opersys.com>
In message <4259FA09.8040508@opersys.com> you wrote:
>
> I've been trying to get a 2.6.x kernel working with a TQM860L board
> with little success. I can get 2.6.11.6 to boot and _sometimes_ get
> to a shell, but most of the times it dies while starting init. From
> reading the archives, this looks very much like an SDRAM config issue
> (i.e. dies mostly when bursting.) Has anyone on this list got a
> 2.6.x kernel working with the TQM860L?
No, in this case it is not a SDRAM issue. I understand that you're
using U-Boot on the board, and this is one of our reference platforms
and among the best tested systems with U-Boot.
Did you apply Marcelo's patch?
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
Nobody goes to that restaurant anymore. It's too crowded.
^ permalink raw reply
* Re: 2.6.x with TQM860L
From: Pantelis Antoniou @ 2005-04-11 6:08 UTC (permalink / raw)
To: karim; +Cc: linuxppc-embedded
In-Reply-To: <4259FA09.8040508@opersys.com>
[-- Attachment #1: Type: text/plain, Size: 866 bytes --]
Karim Yaghmour wrote:
> I've been trying to get a 2.6.x kernel working with a TQM860L board
> with little success. I can get 2.6.11.6 to boot and _sometimes_ get
> to a shell, but most of the times it dies while starting init. From
> reading the archives, this looks very much like an SDRAM config issue
> (i.e. dies mostly when bursting.) Has anyone on this list got a
> 2.6.x kernel working with the TQM860L?
>
> Thanks,
>
> Karim
Karim hi
You need the following small patch.
For all the gory details follow the thread
"8xx v2.6 TLB problems and suggested workaround"
Latest 2.6.12-rc2 works for me.
I don't know if there are any specific problems with TQM860L.
Please be aware that the serial driver has changed
arch/ppc/8xx_io/uart.c -> drivers/serial/cpm_uart
Also if you use the FEC do give a whirl at drivers/net/fec_8xx.
Regards
Pantelis
[-- Attachment #2: 8xx-tlbie.patch --]
[-- Type: text/x-patch, Size: 583 bytes --]
--- linux-2.5/arch/ppc/mm/init.c 2005-04-01 13:33:07.000000000 +0300
+++ linux-2.5-intracom/arch/ppc/mm/init.c 2005-04-05 10:28:04.000000000 +0300
@@ -620,9 +620,10 @@
struct page *page = pfn_to_page(pfn);
if (!PageReserved(page)
&& !test_bit(PG_arch_1, &page->flags)) {
- if (vma->vm_mm == current->active_mm)
- __flush_dcache_icache((void *) address);
- else
+ if (vma->vm_mm == current->active_mm) {
+ _tlbie(address);
+ __flush_dcache_icache((void *)address);
+ } else
flush_dcache_icache_page(page);
set_bit(PG_arch_1, &page->flags);
}
^ permalink raw reply
* 2.6.x with TQM860L
From: Karim Yaghmour @ 2005-04-11 4:16 UTC (permalink / raw)
To: linuxppc-embedded
I've been trying to get a 2.6.x kernel working with a TQM860L board
with little success. I can get 2.6.11.6 to boot and _sometimes_ get
to a shell, but most of the times it dies while starting init. From
reading the archives, this looks very much like an SDRAM config issue
(i.e. dies mostly when bursting.) Has anyone on this list got a
2.6.x kernel working with the TQM860L?
Thanks,
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546
^ permalink raw reply
* [PATCH] pmac: Improve sleep code of tumbler driver
From: Benjamin Herrenschmidt @ 2005-04-11 2:00 UTC (permalink / raw)
To: Andrew Morton
Cc: Takashi Iwai, linuxppc-dev list, debian-powerpc@lists.debian.org
Hi !
This patch (applies on top of my previous one adding support for newer
machines) improves the behaviour of the "tumbler/snapper" driver used on
newer PowerMacs during sleep. It properly set the HW mutes to shut down
amplifiers and does an analog shutdown of the codec. That might improve
power consumption during sleep on a number of machines.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/sound/ppc/tumbler.c
===================================================================
--- linux-work.orig/sound/ppc/tumbler.c 2005-04-11 10:50:18.000000000 +1000
+++ linux-work/sound/ppc/tumbler.c 2005-04-11 11:57:07.000000000 +1000
@@ -94,12 +94,17 @@
pmac_gpio_t hp_detect;
int headphone_irq;
unsigned int master_vol[2];
+ unsigned int save_master_switch[2];
unsigned int master_switch[2];
unsigned int mono_vol[VOL_IDX_LAST_MONO];
unsigned int mix_vol[VOL_IDX_LAST_MIX][2]; /* stereo volumes for tas3004 */
int drc_range;
int drc_enable;
int capture_source;
+ int anded_reset;
+ int auto_mute_notify;
+ int reset_on_sleep;
+ u8 acs;
} pmac_tumbler_t;
@@ -654,7 +659,8 @@
/*
- * mute switches
+ * mute switches. FIXME: Turn that into software mute when both outputs are muted
+ * to avoid codec reset on ibook M7
*/
enum { TUMBLER_MUTE_HP, TUMBLER_MUTE_AMP };
@@ -696,8 +702,11 @@
{
if (! mix->i2c.client)
return -ENODEV;
- return i2c_smbus_write_byte_data(mix->i2c.client, TAS_REG_ACS,
- mix->capture_source ? 2 : 0);
+ if (mix->capture_source)
+ mix->acs = mix->acs |= 2;
+ else
+ mix->acs &= ~2;
+ return i2c_smbus_write_byte_data(mix->i2c.client, TAS_REG_ACS, mix->acs);
}
static int snapper_info_capture_source(snd_kcontrol_t *kcontrol, snd_ctl_elem_info_t *uinfo)
@@ -855,8 +864,7 @@
static struct work_struct device_change;
-static void
-device_change_handler(void *self)
+static void device_change_handler(void *self)
{
pmac_t *chip = (pmac_t*) self;
pmac_tumbler_t *mix;
@@ -865,6 +873,33 @@
return;
mix = chip->mixer_data;
+ snd_assert(mix, return);
+
+ if (tumbler_detect_headphone(chip)) {
+ /* mute speaker */
+ check_mute(chip, &mix->hp_mute, 0, mix->auto_mute_notify,
+ chip->master_sw_ctl);
+ if (mix->anded_reset)
+ big_mdelay(10);
+ check_mute(chip, &mix->amp_mute, 1, mix->auto_mute_notify,
+ chip->speaker_sw_ctl);
+ mix->drc_enable = 0;
+ } else {
+ /* unmute speaker */
+ check_mute(chip, &mix->amp_mute, 0, mix->auto_mute_notify,
+ chip->speaker_sw_ctl);
+ if (mix->anded_reset)
+ big_mdelay(10);
+ check_mute(chip, &mix->hp_mute, 1, mix->auto_mute_notify,
+ chip->master_sw_ctl);
+ mix->drc_enable = 1;
+ }
+ if (mix->auto_mute_notify) {
+ snd_ctl_notify(chip->card, SNDRV_CTL_EVENT_MASK_VALUE,
+ &chip->hp_detect_ctl->id);
+ snd_ctl_notify(chip->card, SNDRV_CTL_EVENT_MASK_VALUE,
+ &chip->drc_sw_ctl->id);
+ }
/* first set the DRC so the speaker do not explode -ReneR */
if (chip->model == PMAC_TUMBLER)
@@ -879,31 +914,11 @@
static void tumbler_update_automute(pmac_t *chip, int do_notify)
{
if (chip->auto_mute) {
- pmac_tumbler_t *mix = chip->mixer_data;
+ pmac_tumbler_t *mix;
+ mix = chip->mixer_data;
snd_assert(mix, return);
- if (tumbler_detect_headphone(chip)) {
- /* mute speaker */
- check_mute(chip, &mix->amp_mute, 1, do_notify, chip->speaker_sw_ctl);
- check_mute(chip, &mix->hp_mute, 0, do_notify, chip->master_sw_ctl);
- mix->drc_enable = 0;
-
- } else {
- /* unmute speaker */
- check_mute(chip, &mix->amp_mute, 0, do_notify, chip->speaker_sw_ctl);
- check_mute(chip, &mix->hp_mute, 1, do_notify, chip->master_sw_ctl);
- mix->drc_enable = 1;
- }
- if (do_notify) {
- snd_ctl_notify(chip->card, SNDRV_CTL_EVENT_MASK_VALUE,
- &chip->hp_detect_ctl->id);
- snd_ctl_notify(chip->card, SNDRV_CTL_EVENT_MASK_VALUE,
- &chip->drc_sw_ctl->id);
- }
-
- /* finally we need to schedule an update of the mixer values
- (master and DRC are enough for now) -ReneR */
+ mix->auto_mute_notify = do_notify;
schedule_work(&device_change);
-
}
}
#endif /* PMAC_SUPPORT_AUTOMUTE */
@@ -1002,15 +1017,53 @@
{
pmac_tumbler_t *mix = chip->mixer_data;
- write_audio_gpio(&mix->audio_reset, 0);
- big_mdelay(200);
- write_audio_gpio(&mix->audio_reset, 1);
- big_mdelay(100);
- write_audio_gpio(&mix->audio_reset, 0);
- big_mdelay(100);
+ if (mix->anded_reset) {
+ write_audio_gpio(&mix->hp_mute, 0);
+ write_audio_gpio(&mix->amp_mute, 0);
+ big_mdelay(200);
+ write_audio_gpio(&mix->hp_mute, 1);
+ write_audio_gpio(&mix->amp_mute, 1);
+ big_mdelay(100);
+ write_audio_gpio(&mix->hp_mute, 0);
+ write_audio_gpio(&mix->amp_mute, 0);
+ big_mdelay(100);
+ } else {
+ write_audio_gpio(&mix->audio_reset, 0);
+ big_mdelay(200);
+ write_audio_gpio(&mix->audio_reset, 1);
+ big_mdelay(100);
+ write_audio_gpio(&mix->audio_reset, 0);
+ big_mdelay(100);
+ }
}
#ifdef CONFIG_PMAC_PBOOK
+/* suspend mixer */
+static void tumbler_suspend(pmac_t *chip)
+{
+ pmac_tumbler_t *mix = chip->mixer_data;
+
+ if (mix->headphone_irq >= 0)
+ disable_irq(mix->headphone_irq);
+ mix->save_master_switch[0] = mix->master_switch[0];
+ mix->save_master_switch[1] = mix->master_switch[1];
+ mix->master_switch[0] = mix->master_switch[1] = 0;
+ tumbler_set_master_volume(mix);
+ if (!mix->anded_reset) {
+ write_audio_gpio(&mix->amp_mute, 1);
+ write_audio_gpio(&mix->hp_mute, 1);
+ }
+ if (chip->model == PMAC_SNAPPER) {
+ mix->acs |= 1;
+ i2c_smbus_write_byte_data(mix->i2c.client, TAS_REG_ACS, mix->acs);
+ }
+ if (mix->anded_reset) {
+ write_audio_gpio(&mix->amp_mute, 1);
+ write_audio_gpio(&mix->hp_mute, 1);
+ } else
+ write_audio_gpio(&mix->audio_reset, 1);
+}
+
/* resume mixer */
static void tumbler_resume(pmac_t *chip)
{
@@ -1018,6 +1071,9 @@
snd_assert(mix, return);
+ mix->acs &= ~1;
+ mix->master_switch[0] = mix->save_master_switch[0];
+ mix->master_switch[1] = mix->save_master_switch[1];
tumbler_reset_audio(chip);
if (mix->i2c.client && mix->i2c.init_client) {
if (mix->i2c.init_client(&mix->i2c) < 0)
@@ -1041,6 +1097,8 @@
tumbler_set_master_volume(mix);
if (chip->update_automute)
chip->update_automute(chip, 0);
+ if (mix->headphone_irq >= 0)
+ enable_irq(mix->headphone_irq);
}
#endif
@@ -1103,9 +1161,9 @@
int i, err;
pmac_tumbler_t *mix;
u32 *paddr;
- struct device_node *tas_node;
+ struct device_node *tas_node, *np;
char *chipname;
-
+
#ifdef CONFIG_KMOD
if (current->fs->root)
request_module("i2c-keywest");
@@ -1119,7 +1177,18 @@
chip->mixer_data = mix;
chip->mixer_free = tumbler_cleanup;
+ mix->anded_reset = 0;
+ mix->reset_on_sleep = 1;
+ for (np = chip->node->child; np; np = np->sibling) {
+ if (!strcmp(np->name, "sound")) {
+ if (get_property(np, "has-anded-reset", NULL))
+ mix->anded_reset = 1;
+ if (get_property(np, "layout-id", NULL))
+ mix->reset_on_sleep = 0;
+ break;
+ }
+ }
if ((err = tumbler_init(chip)) < 0)
return err;
@@ -1178,6 +1247,7 @@
return err;
#ifdef CONFIG_PMAC_PBOOK
+ chip->suspend = tumbler_suspend;
chip->resume = tumbler_resume;
#endif
^ permalink raw reply
* Re: how to get busybox shell prompt on console port?
From: Robert P. J. Day @ 2005-04-10 20:58 UTC (permalink / raw)
To: Kylo Ginsberg; +Cc: Embedded PPC Linux list
In-Reply-To: <4259615E.2070608@kylo.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 601 bytes --]
On Sun, 10 Apr 2005, Kylo Ginsberg wrote:
> Fwiw, I explicitly created the CPM devices; note that the
> major/minor match those of your NULL nodes. I'm running 2.6.11.
> I'm fuzzy re if/how these devices should be automagically created by
> the kernel.
>
> mknod ttyCPM0 c 204 46
> mknod ttyCPM1 c 204 47
> chmod 660 ttyCPM*
>
...
> crw------- 1 root root 204, 46 Dec 31 1969 <NULL>0
> crw------- 1 root root 204, 47 Dec 31 1969 <NULL>1
well, since i'm using devfs, i'm assuming that's what i get by
default. ok, that clears up some of the confusion. thanks.
rday
^ permalink raw reply
* Re: how to get busybox shell prompt on console port?
From: Kylo Ginsberg @ 2005-04-10 17:24 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Embedded PPC Linux list
In-Reply-To: <Pine.LNX.4.61.0504101302010.28010@localhost.localdomain>
[-- Attachment #1: Type: text/html, Size: 3158 bytes --]
^ permalink raw reply
* Re: how to get busybox shell prompt on console port?
From: Robert P. J. Day @ 2005-04-10 17:06 UTC (permalink / raw)
To: Kylo Ginsberg; +Cc: Embedded PPC Linux list
In-Reply-To: <42594D18.4070403@kylo.net>
On Sun, 10 Apr 2005, Kylo Ginsberg wrote:
> I use this line in /etc/inittab (assuming you've built busybox to include sh):
>
> ttyCPM0::respawn:-/bin/sh
(first, a caveat: even though this is the 2.6 kernel, i'm still using
devfs for historical reasons. that will change shortly but may be
part of my problems.)
i'm pretty sure i tried that combo, and several others like it, and i
finally had success with the following entry in /etc/inittab:
::respawn:/bin/sh < /dev/console > /dev/console 2> /dev/console
yes, it's disgusting but it works. once i got a prompt, i noticed
that these are the contents of /dev:
crw------- 1 root root 204, 46 Dec 31 1969 <NULL>0
crw------- 1 root root 204, 47 Dec 31 1969 <NULL>1
crw------- 1 root root 5, 1 Oct 2 08:56 console
crw-rw-rw- 1 root root 1, 7 Dec 31 1969 full
drwxr-xr-x 1 root root 0 Dec 31 1969 input
crw-r----- 1 root root 1, 2 Dec 31 1969 kmem
crw-r--r-- 1 root root 1, 11 Dec 31 1969 kmsg
drwxr-xr-x 1 root root 0 Dec 31 1969 loop
crw-r----- 1 root root 1, 1 Dec 31 1969 mem
drwxr-xr-x 1 root root 0 Dec 31 1969 misc
crw-rw-rw- 1 root root 1, 3 Dec 31 1969 null
crw-r----- 1 root root 1, 4 Dec 31 1969 port
crw-rw-rw- 1 root root 5, 2 Dec 31 1969 ptmx
drwxr-xr-x 1 root root 0 Dec 31 1969 pts
drwxr-xr-x 1 root root 0 Dec 31 1969 pty
crw-r--r-- 1 root root 1, 8 Dec 31 1969 random
drwxr-xr-x 1 root root 0 Dec 31 1969 rd
lr-xr-xr-x 1 root root 4 Sep 25 1969 root -> rd/0
drwxr-xr-x 1 root root 0 Dec 31 1969 shm
crw-rw-rw- 1 root root 5, 0 Dec 31 1969 tty
crw-r--r-- 1 root root 1, 9 Dec 31 1969 urandom
crw-rw-rw- 1 root root 1, 5 Dec 31 1969 zero
in other words, no /dev/ttyCPM0 which may be why that first solution
never worked (i'm still fuzzy on support for the serial/console ports
so i'm reading up on that now.) but given that i have a /dev/console,
i'll stick with that for now until i have a better fix.
and what's the two "NULL" entries up there? those are new to me.
rday
^ permalink raw reply
* Re: cross-compiling under cygwin?
From: Wolfgang Denk @ 2005-04-10 16:59 UTC (permalink / raw)
To: Howard, Marc; +Cc: Embedded PPC Linux list
In-Reply-To: <91B22F93A880FA48879475E134D6F0BEB9C02A@CA1EXCLV02.adcorp.kla-tencor.com>
In message <91B22F93A880FA48879475E134D6F0BEB9C02A@CA1EXCLV02.adcorp.kla-tencor.com> you wrote:
>
> Yes you can run NFS on Windows. The systems we ship inside our
> equipment have a Win2k Server host and the embedded boards hang off of
And this really supports things like special files, user and group
id's, permissions including set-uid and hardlinks and all that?
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
Hello! I'm from outer space, and I've made myself look like a signa-
ture. While you are reading this, I'm having sex with your eyes. I
know it feels good to you, because you're smiling. I'm very horny, so
send me to someone else when you've had enough. Thanks!
Sincerely, A Stranger in a Strange Land
^ permalink raw reply
* Re: how to get busybox shell prompt on console port?
From: Kylo Ginsberg @ 2005-04-10 15:58 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Embedded PPC Linux list
In-Reply-To: <Pine.LNX.4.61.0504101046030.8150@localhost.localdomain>
I use this line in /etc/inittab (assuming you've built busybox to
include sh):
ttyCPM0::respawn:-/bin/sh
Robert P. J. Day wrote:
> i'm still wrestling with how to get my 8xx-based board's shell
>prompt to show up on the console port. i've built a simple
>2.6.11.7-based kernel and (busybox-based) root filesystem and, fairly
>quickly, i realized i needed to use the following kernel boot line:
>
> Linux/PPC load: rw root=/dev/ram0 console=ttyCPM0,9600
>
> as the boot proceeds, i eventually see:
>
> Serial: CPM driver $Revision: 0.01 $
> ttyCPM0 at MMIO 0xfa200a80 (irq = 20) is a CPM UART
> ttyCPM1 at MMIO 0xfa200a00 (irq = 46) is a CPM UART
>
>which seems to be a good sign. however, after all the standard boot
>output, i'm left with no shell prompt, and i'm assuming it's just
>because i haven't correctly started the shell thru /etc/inittab with
>the correct parameters to have it talk to that console port.
>
> what would be the correct invocation of /bin/sh in /etc/inittab to
>reflect my serial/console port setup above? thanks.
>
>rday
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
^ permalink raw reply
* how to get busybox shell prompt on console port?
From: Robert P. J. Day @ 2005-04-10 14:51 UTC (permalink / raw)
To: Embedded PPC Linux list
i'm still wrestling with how to get my 8xx-based board's shell
prompt to show up on the console port. i've built a simple
2.6.11.7-based kernel and (busybox-based) root filesystem and, fairly
quickly, i realized i needed to use the following kernel boot line:
Linux/PPC load: rw root=/dev/ram0 console=ttyCPM0,9600
as the boot proceeds, i eventually see:
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xfa200a80 (irq = 20) is a CPM UART
ttyCPM1 at MMIO 0xfa200a00 (irq = 46) is a CPM UART
which seems to be a good sign. however, after all the standard boot
output, i'm left with no shell prompt, and i'm assuming it's just
because i haven't correctly started the shell thru /etc/inittab with
the correct parameters to have it talk to that console port.
what would be the correct invocation of /bin/sh in /etc/inittab to
reflect my serial/console port setup above? thanks.
rday
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Matthew T. Atkinson @ 2005-04-10 14:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113089907.9517.446.camel@gaston>
'ello,
On Sun, 2005-04-10 at 09:38 +1000, Benjamin Herrenschmidt wrote:
> If you set apps like xmms to actually use alsa output, you can have
> mixing but for that, you have to enable the dmix plugin in your alsa
> config. Look for infos about that on this list archive.
Thanks to both who suggested this; at last its all working with multiple
apps!
best regards,
--
Matthew T. Atkinson <matthew@agrip.org.uk>
^ permalink raw reply
* Re: Sound drivers for newer machines: need help
From: Ben Hill @ 2005-04-10 12:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1113006674.9568.414.camel@gaston>
On Sat, 2005-04-09 at 10:31 +1000, Benjamin Herrenschmidt wrote:
> echo `cat /proc/device-tree/model`
PowerBook5,6
>
> for i in `find /proc/device-tree -name layout-id -print`; do echo $i && hexdump -n4 $i; done
find: /proc/device-tree/uni-n@f8000000/i2c@f8001000/i2c-bus@1/fan@5c/pulses/rev: No such file or directory
/proc/device-tree/pci@f2000000/mac-io@17/i2s@0/i2s-a@10000/sound/layout-id
0000000 0000 0046
0000004
HTH
--
ben@serosoft.com - www.seigan.org
PGP Key fingerprint = 4309 1C58 5143 AFAC F69E 11CD 76FD 56D4 1223 E387
^ permalink raw reply
* RE: 8xx v2.6 TLB problems and suggested workaround
From: Joakim Tjernlund @ 2005-04-10 10:08 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded
In-Reply-To: <20050409223721.GA27454@logos.cnet>
> -----Original Message-----
> From: Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com]
> On Sat, Apr 09, 2005 at 09:03:54PM +0200, Joakim Tjernlund wrote:
> > >
> > > On Apr 8, 2005, at 7:07 AM, Marcelo Tosatti wrote:
[SNIP]
> > I still think this can be resolved in fault.c. Replace
> > andis. r11, r10, 0x0200 /* If set, indicates store op */
> > beq 2f
> > in the DTLB Error handler with
> > andis. r11, r10, 0x4800 /* If set, indicates invalid pte or protection violation */
> > bne 2f
>
> Why does the current code jump to page fault handler in case of store operation?
It doesn't. It jumps if some other bit is set as well. In your dcbst case it seems like invalid
is set too. I hope that will be enough to work something out in fault.c.
>
> Out of curiosity, aren't there any other valid bit combinations for DSISR other
> than 0x4800 which should allow a fastpath DataTLBError ?
Don't know, hopefully Dan knows.
>
> I can't find DSISR settings in MPC860UM.pdf neither paper manual. AFAICS it
> always refer to the PEM when talking about DSISR bit assignments.
>
> I can't find section "7-15" as you mentioned in the other email.
It is page 7-15 and I think(not having the manual handy) that chapter 7 describes the
different exceptions including the DTLB Error.
>
> > In fault.c you can check if both store and invalid is set simultaneously. If it is, clear
> > the store flag and continue as usual.
>
> One point is that by changing the in-kernel dcbst implementation userspace is
> still vulnerable to the problem.
>
> Now fixing the exception handler to deal with such boggosity as Joakim proposes is
> complete - it handles userspace dcbst callers.
Yes, ldso uses dcbst and icbi. Currently it works fine because a normal store
has been performed before dcbst/icbi is executed.
Jocke
^ permalink raw reply
* Re: [PATCH] pmac: sound support for latest laptops
From: Antonio-M. Corbi Bellot @ 2005-04-10 8:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Takashi Iwai, linuxppc-dev list, debian-powerpc@lists.debian.org,
Andrew Morton
In-Reply-To: <1113113792.9517.476.camel@gaston>
El dom, 10-04-2005 a las 16:16 +1000, Benjamin Herrenschmidt escribió:
> Hi !
>
> This patch hacks the current Alsa snd-powermac driver to add support for
> recent machine models with the tas3004 chip, that is basically new
> laptop models.
It's working here (pbook 12" post-feb05) superb!.
Thanks (once again) :=) Ben!
Antonio Corbi.
^ permalink raw reply
* Re: iBook G3 owners
From: David Woodhouse @ 2005-04-10 8:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1113091621.9518.450.camel@gaston>
On Sun, 2005-04-10 at 10:07 +1000, Benjamin Herrenschmidt wrote:
> Can you check that you have the very latest versions of these
> patches ?
> I updated them a couple of time since I posted the message...
The md5sums of the patches I have precisely match the md5sums of the
patches which are currently up for download:
fc63b0d57d26f2dec44d0ba1667eb263 linux-2.6.11-ppc32-pmac-sleep-fix.patch
29792fdd1970b9447d06a2bb044e48e0 linux-2.6.11-cpufreq-add-suspend.patch
dcdb468b9325c1835e9992034b7d8a28 linux-2.6.11-ppc32-750-erratum-fix.patch
689353b33f3bdc7759692a4cccdb24fa linux-2.6.11-ppc32-cpufreq-gpio-off.patch
A kernel without _any_ of these patches survived an overnight sleep, and
in fact cpufreq was working again too. I'll try with just the cpufreq
patches.
--
dwmw2
^ permalink raw reply
* [PATCH] pmac: sound support for latest laptops
From: Benjamin Herrenschmidt @ 2005-04-10 6:16 UTC (permalink / raw)
To: debian-powerpc@lists.debian.org, linuxppc-dev list
Cc: Takashi Iwai, Andrew Morton
Hi !
This patch hacks the current Alsa snd-powermac driver to add support for
recent machine models with the tas3004 chip, that is basically new
laptop models. The Mac Mini is _NOT_ yet supported by this patch (soon
soon ...). The G5s (iMac or Desktop) will need the rewritten sound
driver on which I'm working on (I _might_ get a hack for analog only on
some G5s on the current driver, but no promise).
diff -urN linux-2.6.12-rc2/sound/ppc/pmac.c linux-2.6.12-rc2+snd/sound/ppc/pmac.c
--- linux-2.6.12-rc2/sound/ppc/pmac.c 2005-04-10 15:21:33.000000000 +1000
+++ linux-2.6.12-rc2+snd/sound/ppc/pmac.c 2005-04-10 15:16:07.000000000 +1000
@@ -881,7 +881,8 @@
{
struct device_node *sound;
unsigned int *prop, l;
-
+ u32 layout_id = 0;
+
if (_machine != _MACH_Pmac)
return -ENODEV;
@@ -929,6 +930,9 @@
prop = (unsigned int *) get_property(sound, "sub-frame", NULL);
if (prop && *prop < 16)
chip->subframe = *prop;
+ prop = (unsigned int *) get_property(sound, "layout-id", NULL);
+ if (prop)
+ layout_id = *prop;
/* This should be verified on older screamers */
if (device_is_compatible(sound, "screamer")) {
chip->model = PMAC_SCREAMER;
@@ -961,12 +965,22 @@
chip->freq_table = tumbler_freqs;
chip->control_mask = MASK_IEPC | 0x11; /* disable IEE */
}
- if (device_is_compatible(sound, "AOAKeylargo")) {
- /* Seems to support the stock AWACS frequencies, but has
- a snapper mixer */
- chip->model = PMAC_SNAPPER;
- // chip->can_byte_swap = 0; /* FIXME: check this */
- chip->control_mask = MASK_IEPC | 0x11; /* disable IEE */
+ if (device_is_compatible(sound, "AOAKeylargo") ||
+ device_is_compatible(sound, "AOAbase")) {
+ /* For now, only support very basic TAS3004 based machines with
+ * single frequency until proper i2s control is implemented
+ */
+ switch(layout_id) {
+ case 0x48:
+ case 0x46:
+ case 0x33:
+ case 0x29:
+ chip->num_freqs = ARRAY_SIZE(tumbler_freqs);
+ chip->model = PMAC_SNAPPER;
+ chip->can_byte_swap = 0; /* FIXME: check this */
+ chip->control_mask = MASK_IEPC | 0x11; /* disable IEE */
+ break;
+ }
}
prop = (unsigned int *)get_property(sound, "device-id", NULL);
if (prop)
diff -urN linux-2.6.12-rc2/sound/ppc/tumbler.c linux-2.6.12-rc2+snd/sound/ppc/tumbler.c
--- linux-2.6.12-rc2/sound/ppc/tumbler.c 2005-03-05 10:20:29.000000000 +1100
+++ linux-2.6.12-rc2+snd/sound/ppc/tumbler.c 2005-04-10 15:08:00.000000000 +1000
@@ -37,6 +37,8 @@
#include <asm/irq.h>
#ifdef CONFIG_PPC_HAS_FEATURE_CALLS
#include <asm/pmac_feature.h>
+#else
+#error old crap
#endif
#include "pmac.h"
#include "tumbler_volume.h"
@@ -950,10 +952,10 @@
}
/* find an audio device and get its address */
-static unsigned long tumbler_find_device(const char *device, pmac_gpio_t *gp, int is_compatible)
+static long tumbler_find_device(const char *device, pmac_gpio_t *gp, int is_compatible)
{
struct device_node *node;
- u32 *base;
+ u32 *base, addr;
if (is_compatible)
node = find_compatible_audio_device(device);
@@ -966,21 +968,31 @@
base = (u32 *)get_property(node, "AAPL,address", NULL);
if (! base) {
- snd_printd("cannot find address for device %s\n", device);
- return -ENODEV;
- }
+ base = (u32 *)get_property(node, "reg", NULL);
+ if (!base) {
+ snd_printd("cannot find address for device %s\n", device);
+ return -ENODEV;
+ }
+ /* this only work if PPC_HAS_FEATURE_CALLS is set as we
+ * are only getting the low part of the address
+ */
+ addr = *base;
+ if (addr < 0x50)
+ addr += 0x50;
+ } else
+ addr = *base;
#ifdef CONFIG_PPC_HAS_FEATURE_CALLS
- gp->addr = (*base) & 0x0000ffff;
+ gp->addr = addr & 0x0000ffff;
#else
- gp->addr = ioremap((unsigned long)(*base), 1);
+ gp->addr = ioremap((unsigned long)addr, 1);
#endif
+ /* Try to find the active state, default to 0 ! */
base = (u32 *)get_property(node, "audio-gpio-active-state", NULL);
if (base)
gp->active_state = *base;
else
- gp->active_state = 1;
-
+ gp->active_state = 0;
return (node->n_intrs > 0) ? node->intrs[0].line : 0;
}
@@ -1039,11 +1051,16 @@
pmac_tumbler_t *mix = chip->mixer_data;
snd_assert(mix, return -EINVAL);
- tumbler_find_device("audio-hw-reset", &mix->audio_reset, 0);
- tumbler_find_device("amp-mute", &mix->amp_mute, 0);
- tumbler_find_device("headphone-mute", &mix->hp_mute, 0);
+ if (tumbler_find_device("audio-hw-reset", &mix->audio_reset, 0) < 0)
+ tumbler_find_device("hw-reset", &mix->audio_reset, 1);
+ if (tumbler_find_device("amp-mute", &mix->amp_mute, 0) < 0)
+ tumbler_find_device("amp-mute", &mix->amp_mute, 1);
+ if (tumbler_find_device("headphone-mute", &mix->hp_mute, 0) < 0)
+ tumbler_find_device("headphone-mute", &mix->hp_mute, 1);
irq = tumbler_find_device("headphone-detect", &mix->hp_detect, 0);
if (irq < 0)
+ irq = tumbler_find_device("headphone-detect", &mix->hp_detect, 1);
+ if (irq < 0)
irq = tumbler_find_device("keywest-gpio15", &mix->hp_detect, 1);
tumbler_reset_audio(chip);
@@ -1109,9 +1126,13 @@
/* set up TAS */
tas_node = find_devices("deq");
if (tas_node == NULL)
+ tas_node = find_devices("codec");
+ if (tas_node == NULL)
return -ENODEV;
paddr = (u32 *)get_property(tas_node, "i2c-address", NULL);
+ if (paddr == NULL)
+ paddr = (u32 *)get_property(tas_node, "reg", NULL);
if (paddr)
mix->i2c.addr = (*paddr) >> 1;
else
@@ -1129,7 +1150,7 @@
if ((err = snd_pmac_keywest_init(&mix->i2c)) < 0)
return err;
-
+
/*
* build mixers
*/
@@ -1156,7 +1177,6 @@
if ((err = snd_ctl_add(chip->card, chip->drc_sw_ctl)) < 0)
return err;
-
#ifdef CONFIG_PMAC_PBOOK
chip->resume = tumbler_resume;
#endif
^ permalink raw reply
* Problem with customized MPC5200 board(copy from lite5200 design)
From: Yeo Keewee @ 2005-04-10 4:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050410020004.967A967B3E@ozlabs.org>
Hi,
Our hardware group had designed a mpc5200 board using the same design
as lite5200.
Currently, we are using bdi2000(icecube config) to attempt to access
the internal registers. By using the same procedure on lite5200, we
can access the registers but we always could not do it on our board.
Besides a hardware design flaw, is there any other init procedures
that are required to use bdi2000 on our custom board?
Did anyone face this kind of problem?
rgds
Yeo Kee Wee
^ 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