[PATCH] powerpc: Add of_platform support for ROM devices
On Mon, 2006-11-20 at 16:32 +0300, Vitaly Wool wrote: > + > +Required properties: > + > + - device_type : has to be "rom" > + - compatible : Should specify what this ROM device is compatible with > + (i.e. "onenand"). Currently, this is most likely to be "direct-mapped" > + (which corresponds to the MTD physmap mapping driver). > + - regs : Offset and length of the register set (or memory mapping) for > + the device. > + > +Recommended properties : > + > + - bank-width : Width of the flash data bus in bytes. Required > + for the NOR flashes (compatible == "direct-mapped" and others) ONLY. Maybe you should put this in the Required section then, with a note that it's only Recommended for non-NOR flashes. I can easily imagine somebody ignoring every Recommendation section and missing this requirement. > + - partitions : Several pairs of 32-bit values where the first value is > + partition's offset from the start of the device and the second one is > + partition size in bytes with LSB used to signify a read only > + partititon (so, the parition size should always be an even number). ^^^ "partition" misspelled, twice. :) -Hollis
update: consolidated flat device tree code
On Wed, 2006-08-23 at 16:47 +1000, Paul Mackerras wrote: > Hollis Blanchard writes: > > > Still haven't looked to merge Matt's changes (because I'm busy, the > > current code works for me, and they haven't been accepted in u-boot > > yet). > > The other version that was posted had support for modifying an > existing flat tree, which I need for the wrapper code for prep. Are > those "Matt's changes"? Are you thinking of adding that capability to > your version? You can do this now with the ft_set_prop() function, which is what I'm using for Xen. At the moment that function isn't able to modify the size of a property, but Mark is going to adapt his code (which supports that). -- Hollis Blanchard IBM Linux Technology Center
update: consolidated flat device tree code
On Thu, 2006-08-17 at 19:23 -0500, Hollis Blanchard wrote: > - added an explicit copyright statement. On this subject, it's just been asked that the Xen library containing this code be relicensed as LGPL (instead of GPL). Panto, you're the original author of that code. Since we are trying to make a library, I think LGPL makes sense. Is relicensing OK with you? (Matt, this would be relevant to your outstanding patches as well.) -- Hollis Blanchard IBM Linux Technology Center
update: consolidated flat device tree code
On Thu, 2006-08-17 at 19:23 -0500, Hollis Blanchard wrote: > Changes: > - converted some ints to "unsigned", since gcc was generating warnings > and negative lengths don't make sense in the flat data structure. > - added ft_set_prop(), which doesn't yet resize properties but will in > the future. > - added an explicit copyright statement. > > Still haven't looked to merge Matt's changes (because I'm busy, the > current code works for me, and they haven't been accepted in u-boot > yet). > > Current users: Xen > Future users: Mark's Linux bootwrapper code > Potential users: kexec, u-boot Forgot to add that dtc itself is a potential user of this code. -- Hollis Blanchard IBM Linux Technology Center
update: consolidated flat device tree code
Changes: - converted some ints to "unsigned", since gcc was generating warnings and negative lengths don't make sense in the flat data structure. - added ft_set_prop(), which doesn't yet resize properties but will in the future. - added an explicit copyright statement. Still haven't looked to merge Matt's changes (because I'm busy, the current code works for me, and they haven't been accepted in u-boot yet). Current users: Xen Future users: Mark's Linux bootwrapper code Potential users: kexec, u-boot -- Hollis Blanchard IBM Linux Technology Center -- next part -- A non-text attachment was scrubbed... Name: ft_build.c Type: text/x-csrc Size: 12119 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060817/62e3842d/attachment.c -- next part -- A non-text attachment was scrubbed... Name: ft_build.h Type: text/x-chdr Size: 4373 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060817/62e3842d/attachment.h
[RFC] consolidated libdt proposal
On Tue, 2006-08-08 at 11:04 -0700, Mark A. Greer wrote: > > Except for not being able to extend a property (see below), > I think it does meet my needs (at least as I know them today). Great. > However, I was hoping to keep the interfaces in the bootwrapper > similar to the ones used in the kernel. To that end, I had a > routine to find a device node and other routines to find and modify > a property within that node. I didn't notice a "finddevice" type of > function to find a device node. Would you have a problem adding one? The way property modification works now is this: p = ft_get_prop(tree, "/xen/console/interrupts", &len); if ((NULL == p) || (len != foolen)) return; *p = cpu_to_be32(foo); (That does need to be hidden in a yet-to-be-written ft_set_prop().) If necessary, it looks like it would be possible to modify ft_get_prop() to return a pointer to the beginning of the node structure, but is it really necessary? Do you have code that would be difficult to convert to using ft_set_prop(tree, "/node/prop", buf, buflen); ? > > One limitation of the attached code is that it doesn't support changing > > the *size* of properties, though I don't think that would be too > > difficult to add if needed. > > If we're going to allow cmdline editing in the bootwrapper, we would > need to extend the size of a property. We've never really talked about > cmdline editing in the powerpc branch but I assume that its a good > thing(tm). I know I would like to have it so, IMHO, I think we should > add it (and therefore require extending a property). I agree, and it shouldn't be too much work. I'll take a look later this week, if nobody else has. -- Hollis Blanchard IBM Linux Technology Center
[RFC] consolidated libdt proposal
On Sun, 2006-08-06 at 19:38 -0500, Hollis Blanchard wrote: > > Hmm, so we'll have at least three copies of this code: uboot, kernel, > and Xen. Would it make sense to put this stuff into a libdt.a? > Technically, dtc has a "libdt" already, but it's absurdly incomplete > (I don't even know why it's there), so we could just replace it. Mark, I had a look at the code Pantelis wrote for u-boot, and it was pretty easy to adapt to meet Xen's (userspace-based) needs. I've attached my version below (and see ft_setup() at the bottom of the file). Does it meet your requirements for the kernel bootwrapper? One limitation of the attached code is that it doesn't support changing the *size* of properties, though I don't think that would be too difficult to add if needed. Haren, what about using this in kexec-tools? If everybody can use this (I expect small modifications would be needed), I think we should turn it into a library in the dtc source tree. The various projects using it could then include snapshots (to avoid dependencies). In general I'd like to avoid everybody writing and maintaining their own version of this stuff (myself included). -- Hollis Blanchard IBM Linux Technology Center -- next part -- A non-text attachment was scrubbed... Name: ft_build.c Type: text/x-csrc Size: 14053 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060807/def75069/attachment.c -- next part -- A non-text attachment was scrubbed... Name: ft_build.h Type: text/x-chdr Size: 4308 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060807/def75069/attachment.h
OLS 2005 attendees
As Ottawa Linux Symposium 2005 approaches, I've made a wiki page listing some of the PowerPC people attending, preseeding it with some people I already know will be there: http://oss.gonicus.de/openpower/index.php/LinuxSymposium2005 If you're going, you can add your info to the list and maybe we can all get together... -Hollis
OLS 2005 attendees
As Ottawa Linux Symposium 2005 approaches, I've made a wiki page listing some of the PowerPC people attending, preseeding it with some people I already know will be there: http://oss.gonicus.de/openpower/index.php/LinuxSymposium2005 If you're going, you can add your info to the list and maybe we can all get together... -Hollis
[U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
On May 19, 2005, at 8:18 AM, Wolfgang Denk wrote: > > But my biggest concern is that we should try to come up with a > solution that has a wider acceptance. Especially from the U-Boot > point of view it is not exactly nice that each of PowerPC, ARM and > MIPS use their very own, completely incompatible way of passing in- > formation from the boot loader to the kernel. > > As is, your proposal will add just another incompatible way of doing > the same thing (of course we will have to stay backward compatible > with U-Boot to allow booting older kernels, too). > > Why don't we try to come up with a solution that is acceptable to the > other architectures as well? > > Maybe you want to post the RFC to lkml, or at least to the > linux-arm-kernel and linux-mips mailing lists? As you observe, having multiple incompatible communication mechanisms is an issue of u-boot code maintenance. Since you are the most affected party, perhaps you could propose something for all the architectures? You're obviously much more in tune with the needs of ARM and MIPS... In the meantime, it sounds like this device tree stuff solves ppc64's problem in a way the maintainers are happy with, so it's hard to ask them to come up with a solution to a problem they don't have. -Hollis
email message sizes
On Monday 10 January 2005 15:22, Hollis Blanchard wrote: > Hi all, I am one of two people who moderates these mailing lists. On > occasion, people send large emails to these lists. I am of the opinion > that 1MB emails should not be mass-mailed, but if you all have no > problem with that then I will approve them. > > So are any of you on modems, or operate near the limits of your mail > quotas? I'd like to hear comments either way: how large is ok to post > to these mailing lists? So far I have received 5 private mails indicating that 100KB is a reasonable maximum. If you disagree please speak up... -Hollis
email message sizes
Hi all, I am one of two people who moderates these mailing lists. On occasion, people send large emails to these lists. I am of the opinion that 1MB emails should not be mass-mailed, but if you all have no problem with that then I will approve them. So are any of you on modems, or operate near the limits of your mail quotas? I'd like to hear comments either way: how large is ok to post to these mailing lists? -Hollis
405LP - Beech with SSX firmware
On Fri, 2002-12-20 at 17:36, Hollis Blanchard wrote:
> Hi, this patch (copied from Arctic) allows Beech to boot with SSX
> firmware. If there's a way to detect OpenBIOS vs PIBS (I've asked for
> confirmation) then I think the Beech and Arctic ifdefs could be combined
> in the file. There may not be though, and in the meantime this works.
There is currently no way to detect PIBS, though I think I talked the
developer into including "PIBS" string in the future.
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
-- next part --
= arch/ppc/boot/simple/embed_config.c 1.20 vs edited =
--- 1.20/arch/ppc/boot/simple/embed_config.cSun Dec 15 20:02:08 2002
+++ edited/arch/ppc/boot/simple/embed_config.c Wed Dec 18 15:53:18 2002
@@ -868,12 +868,33 @@
#endif
#ifdef CONFIG_BEECH
-static void
-get_board_info(bd_t **bdp)
+/* Several bootloaders have been used on Beech. We assume either
+ * SSX or OpenBIOS */
+
+#define SSX_BIOS_ADDR 0x
+#define SSX_BIOS_GET_BOARD_INFO 0
+
+struct ssx_bios_id {
+ unsigned int boot_branch; /* Branch to bootcode */
+ char ssx_bios[8]; /* "SSX BIOS" (no \0) */
+ void (*bios_entry_point)(unsigned int, bd_t *); /* Call
bios_entry_point(cmd, &data) */
+};
+
+extern int memcmp(const void *s1, const void *s2, size_t n);
+
+static void get_board_info(bd_t **bdp)
{
- typedef void (*PFV)(bd_t *bd);
- ((PFV)(*(unsigned long *)BOARD_INFO_VECTOR))(*bdp);
- return;
+ struct ssx_bios_id *ssx = (struct ssx_bios_id *)SSX_BIOS_ADDR;
+
+ /* Check for SSX signature */
+
+ if (memcmp(&ssx->ssx_bios, "SSX BIOS", 8) == 0) {
+ ssx->bios_entry_point(SSX_BIOS_GET_BOARD_INFO, *bdp);
+ } else {
+ /* It's not SSX, so assume OpenBIOS */
+ typedef void (*PFV)(bd_t *bd);
+ ((PFV)(*(unsigned long *)BOARD_INFO_VECTOR))(*bdp);
+ }
}
void
BDI-2000
On Tue, 2003-01-07 at 18:40, Muaddi, Cecilia wrote: > > BDI>info > Target state : debug mode > Debug entry cause : entering check stop state > Current PC: 0x0220 You seem to have caused a machine check. For clues look at SRR0 and SRR1, as well as any other registers your CPU sets on machine check (I don't know 8xx - look in your user manual for information on machine checks). -Hollis -- PowerPC Linux IBM Linux Technology Center ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
405LP - Beech with SSX firmware
Hi, this patch (copied from Arctic) allows Beech to boot with SSX
firmware. If there's a way to detect OpenBIOS vs PIBS (I've asked for
confirmation) then I think the Beech and Arctic ifdefs could be combined
in the file. There may not be though, and in the meantime this works.
Please apply to _2_4_devel.
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
-- next part --
= arch/ppc/boot/simple/embed_config.c 1.20 vs edited =
--- 1.20/arch/ppc/boot/simple/embed_config.cSun Dec 15 20:02:08 2002
+++ edited/arch/ppc/boot/simple/embed_config.c Wed Dec 18 15:53:18 2002
@@ -868,12 +868,33 @@
#endif
#ifdef CONFIG_BEECH
-static void
-get_board_info(bd_t **bdp)
+/* Several bootloaders have been used on Beech. We assume either
+ * SSX or OpenBIOS */
+
+#define SSX_BIOS_ADDR 0x
+#define SSX_BIOS_GET_BOARD_INFO 0
+
+struct ssx_bios_id {
+ unsigned int boot_branch; /* Branch to bootcode */
+ char ssx_bios[8]; /* "SSX BIOS" (no \0) */
+ void (*bios_entry_point)(unsigned int, bd_t *); /* Call
bios_entry_point(cmd, &data) */
+};
+
+extern int memcmp(const void *s1, const void *s2, size_t n);
+
+static void get_board_info(bd_t **bdp)
{
- typedef void (*PFV)(bd_t *bd);
- ((PFV)(*(unsigned long *)BOARD_INFO_VECTOR))(*bdp);
- return;
+ struct ssx_bios_id *ssx = (struct ssx_bios_id *)SSX_BIOS_ADDR;
+
+ /* Check for SSX signature */
+
+ if (memcmp(&ssx->ssx_bios, "SSX BIOS", 8) == 0) {
+ ssx->bios_entry_point(SSX_BIOS_GET_BOARD_INFO, *bdp);
+ } else {
+ /* It's not SSX, so assume OpenBIOS */
+ typedef void (*PFV)(bd_t *bd);
+ ((PFV)(*(unsigned long *)BOARD_INFO_VECTOR))(*bdp);
+ }
}
void
405LP RTC warning patch
As David suggested, this patch warns the user if the RTC frequency is
altered by Linux (at least a little time will have been lost during
firmware boot).
Please apply to _2_4_devel.
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
-- next part --
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux 2.4 for PowerPC development tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.1179 -> 1.1180
# arch/ppc/platforms/ibm405lp.c 1.5 -> 1.6
#
# The following is the BitKeeper ChangeSet Log
#
# 02/12/19 hollis at granite.austin.ibm.com1.1180
# print a warning message if RTC frequency is altered
#
#
diff -Nru a/arch/ppc/platforms/ibm405lp.c b/arch/ppc/platforms/ibm405lp.c
--- a/arch/ppc/platforms/ibm405lp.c Thu Dec 19 11:27:45 2002
+++ b/arch/ppc/platforms/ibm405lp.c Thu Dec 19 11:27:45 2002
@@ -288,7 +288,14 @@
mtdcr(DCRN_RTC0_CR1, 0x80); /* Disable update
cycles/interrupts*/
mtdcr(DCRN_RTC0_WRAP, 0); /* toggle NRST & NMR */
mtdcr(DCRN_RTC0_WRAP, 3);
- mtdcr(DCRN_RTC0_CR0, (RTC_DVBITS & 0x7) << 4); /*
input clock */
+
+ /* if necessary, set the input clock frequency */
+ if ((mfdcr(DCRN_RTC0_CR0) >> 4) != RTC_DVBITS) {
+ printk(KERN_WARNING "Warning: RTC frequency was
incorrect\n");
+ mtdcr(DCRN_RTC0_CR0,
+((RTC_DVBITS & 0x7) << 4) |
(mfdcr(DCRN_RTC0_CR0) & 0xf));
+ }
+
mtdcr(DCRN_RTC0_CR1, mfdcr(DCRN_RTC0_CR1) & 0x7f); /*
allow updates */
not_initialized = 0;
405LP RTC reset
On Wed, 2002-12-18 at 15:15, David Gibson wrote: > On Wed, Dec 18, 2002 at 09:38:53AM -0600, Hollis Blanchard wrote: > > > > The only issue I can think of here is the firmware setting it > > incorrectly or not at all. In that case, a few seconds will be expanded > > or compressed, but that's better than time running too fast or slow > > forever, right? > > That's true. Still, I think it might be worth testing what the rate > is set to when we come in, and printing a warning if it's not what we > expect before we adjust it. If it just silently corrects it I could > imagine it being pretty nasty to track down why the device is > losing/gaining time each boot. Sounds like a very good idea. I'll add it to my list unless someone beats me to it. :) -Hollis -- PowerPC Linux IBM Linux Technology Center ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
405LP compile fix
I'm glad I'm not the only one who sometimes doesn't compile-test his
patches... ;)
This patch fixes the Beech build, which is calling the now-nonexistant
function beech_time_init. In actuality beech_calibrate_decr was never called
anyways... :)
Please apply to _2_4_devel.
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
= arch/ppc/platforms/beech.c 1.9 vs edited =
--- 1.9/arch/ppc/platforms/beech.c Thu Dec 12 17:06:37 2002
+++ edited/arch/ppc/platforms/beech.c Tue Dec 17 13:47:47 2002
@@ -253,64 +253,6 @@
/* Set RTS/CTS mode for UART 1 */
*beech_fpga_reg_2 |= FPGA_REG_2_DEFAULT_UART1_N;
-}
-
-void __init
-beech_calibrate_decr(void)
-{
- ulong freq;
- ulong tbl, tbu;
-long i, loop_count;
-u_char sec;
-
- beech_time_init();
-
- /*
-* Actually this is bad for precision, we should have a loop in
-* which we only read the seconds counter. todc_read_val writes
-* the address bytes on every call and this takes a lot of time.
-* Perhaps an nvram_wait_change method returning a time
-* stamp with a loop count as parameter would be the solution.
-*/
- /*
-* Need to make sure the tbl doesn't roll over so if tbu increments
-* during this test, we need to do it again.
-*/
- loop_count = 0;
-
- sec = mfdcr(DCRN_RTC0_SEC) & 0x7f;
-
- do {
- tbu = get_tbu();
-
- for (i = 0 ; i < 1000 ; i++) {/* may take up to 1 second */
- tbl = get_tbl();
-
- if ((mfdcr(DCRN_RTC0_SEC) & 0x7f) != sec) {
- break;
- }
- }
-
- sec = mfdcr(DCRN_RTC0_SEC) & 0x7f;
-
- for (i = 0 ; i < 1000 ; i++) { /* Should take 1 second */
- freq = get_tbl();
-
- if ((mfdcr(DCRN_RTC0_SEC) & 0x7f) != sec) {
- break;
- }
- }
-
- freq -= tbl;
- } while ((get_tbu() != tbu) && (++loop_count < 2));
-
- printk("time_init: decrementer frequency = %lu.%.6lu MHz\n",
- freq/100, freq%100);
-
- tb_ticks_per_jiffy = freq / HZ;
- tb_to_us = mulhwu_scale_factor(freq, 100);
-
- return;
}
/*
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
405LP RTC reset
On Tue, 2002-12-17 at 18:55, David Gibson wrote: > > On Tue, Dec 17, 2002 at 12:43:32PM -0600, Hollis Blanchard wrote: > > Here's the updated 405LP RTC reset diff (after David's move of the RTC > > functions to ibm405lp.c). This patch > > a) does a full RTC reset as specified in the docs > > b) sets the RTC clock speed in RTC "Register A" DV bits, i.e. it does > > not assume the firmware has done this correctly. > > One query though (I didn't think of this earlier) - is it such a great > idea to go setting the reference clock frequency? Unlike most other > drivers, we can't just take over the RTC and do what we like with it > once the kernel boots, because it has to keep running at the same rate > even when the device is rebooting or (mostly) off. The only issue I can think of here is the firmware setting it incorrectly or not at all. In that case, a few seconds will be expanded or compressed, but that's better than time running too fast or slow forever, right? Of course the rate settings must be battery-backed along with the time, so you only need to set it once per RTC power loss. That includes rebooting time and power off time. -Hollis -- PowerPC Linux IBM Linux Technology Center ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
405LP compile fix
On Tue, 2002-12-17 at 13:49, Hollis Blanchard wrote: > > This patch fixes the Beech build, which is calling the now-nonexistant > function beech_time_init. In actuality beech_time_init was never called > anyways... :) Oops, I meant to say "beech_calibrate_decr was never called anyways", but you knew what I meant... -Hollis -- PowerPC Linux IBM Linux Technology Center ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
405LP EBC setup fix
EBC0_B0CR should be set as 16-bit; through an ifdef merging typo it is currently set incorrectly as 8-bit. This prevents 405LP wakeup from succeeding and needs to be fixed. Please apply to _2_4_devel and 2.5. -Hollis -- PowerPC Linux IBM Linux Technology Center -- next part -- = arch/ppc/platforms/beech.c 1.9 vs edited = --- 1.9/arch/ppc/platforms/beech.c Thu Dec 12 17:06:37 2002 +++ edited/arch/ppc/platforms/beech.c Tue Dec 17 11:29:58 2002 @@ -180,7 +180,7 @@ (mfdcri(DCRN_EBC0, BnCR(0)) & EBC0_BnCR_MASK); cr.fields.bs = BEECH_BANK0_EBC_SIZE; cr.fields.bu = EBC0_BnCR_BU_RW; - cr.fields.bw = EBC0_BnCR_BW_8; + cr.fields.bw = EBC0_BnCR_BW_16; mtdcri(DCRN_EBC0, BnCR(0), cr.reg); ap.reg = mfdcri(DCRN_EBC0, BnAP(0)) & EBC0_BnAP_MASK; -- next part -- = arch/ppc/platforms/4xx/beech.c 1.9 vs edited = --- 1.9/arch/ppc/platforms/4xx/beech.c Thu Dec 12 17:06:37 2002 +++ edited/arch/ppc/platforms/4xx/beech.c Tue Dec 17 11:29:58 2002 @@ -180,7 +180,7 @@ (mfdcri(DCRN_EBC0, BnCR(0)) & EBC0_BnCR_MASK); cr.fields.bs = BEECH_BANK0_EBC_SIZE; cr.fields.bu = EBC0_BnCR_BU_RW; - cr.fields.bw = EBC0_BnCR_BW_8; + cr.fields.bw = EBC0_BnCR_BW_16; mtdcri(DCRN_EBC0, BnCR(0), cr.reg); ap.reg = mfdcri(DCRN_EBC0, BnAP(0)) & EBC0_BnAP_MASK;
405LP RTC reset
Here's the updated 405LP RTC reset diff (after David's move of the RTC
functions to ibm405lp.c). This patch
a) does a full RTC reset as specified in the docs
b) sets the RTC clock speed in RTC "Register A" DV bits, i.e. it does
not assume the firmware has done this correctly.
Please apply to _2_4_devel.
Before similar changes can be made to 2.5, the non-todc RTC code will
have to be ported there (which Todd says is on his list :).
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
-- next part --
= arch/ppc/platforms/ibm405lp.h 1.8 vs edited =
--- 1.8/arch/ppc/platforms/ibm405lp.h Tue Dec 17 11:26:06 2002
+++ edited/arch/ppc/platforms/ibm405lp.hTue Dec 17 11:52:10 2002
@@ -860,6 +860,11 @@
#define SLA0_SLPMD_MASK 0x07df /* AND to clear all non-reserved fields
*/
+/* these defines are for the DV bits of RTC0_CR0 */
+#define RTC_DVBITS_4MHZ0 /* 4.194304 MHz */
+#define RTC_DVBITS_1MHZ1 /* 1.048576 MHz */
+#define RTC_DVBITS_33KHZ 2 /* 32.768 KHz */
+
/* Several direct-write DCRs on the 405LP have an interlock requirement,
implemented by a "valid" bit in the low-order bit. This routine handles the
handshaking for these registers, by
= arch/ppc/platforms/ibm405lp.c 1.4 vs edited =
--- 1.4/arch/ppc/platforms/ibm405lp.c Thu Dec 12 17:06:37 2002
+++ edited/arch/ppc/platforms/ibm405lp.cTue Dec 17 11:50:01 2002
@@ -282,12 +282,16 @@
/* Make sure clocks are running */
if (not_initialized) {
- /* Reset the core and ensure it's enabled. We assume
- only that the BIOS has set the correct frequency. */
-
- mtdcr(DCRN_RTC0_WRAP, 0);
+ /* Reset the core and ensure it's enabled. */
+ mtdcr(DCRN_RTC0_WRAP, 0); /* toggle NRST & NMR */
mtdcr(DCRN_RTC0_WRAP, 3);
- mtdcr(DCRN_RTC0_CR1, mfdcr(DCRN_RTC0_CR1) & 0x7f);
+ mtdcr(DCRN_RTC0_CR0, 0x60); /* No divider chain, No
square wave */
+ mtdcr(DCRN_RTC0_CR1, 0x80); /* Disable update
cycles/interrupts*/
+ mtdcr(DCRN_RTC0_WRAP, 0); /* toggle NRST & NMR */
+ mtdcr(DCRN_RTC0_WRAP, 3);
+ mtdcr(DCRN_RTC0_CR0, (RTC_DVBITS & 0x7) << 4); /*
input clock */
+ mtdcr(DCRN_RTC0_CR1, mfdcr(DCRN_RTC0_CR1) & 0x7f); /*
allow updates */
+
not_initialized = 0;
}
= arch/ppc/platforms/beech.h 1.7 vs edited =
--- 1.7/arch/ppc/platforms/beech.h Thu Dec 12 17:10:24 2002
+++ edited/arch/ppc/platforms/beech.h Tue Dec 17 11:50:10 2002
@@ -181,6 +181,8 @@
#define PPC4xx_SERCLK_FREQ 11059200
#define BASE_BAUD (PPC4xx_SERCLK_FREQ / 16)
+#define RTC_DVBITS RTC_DVBITS_1MHZ /* 1MHz RTC */
+
#define PPC4xx_MACHINE_NAME"IBM 405LP Beech"
#define _IO_BASEisa_io_base
= arch/ppc/platforms/arctic2.h 1.1 vs edited =
--- 1.1/arch/ppc/platforms/arctic2.hSun Dec 15 19:59:59 2002
+++ edited/arch/ppc/platforms/arctic2.h Tue Dec 17 11:50:18 2002
@@ -56,6 +56,8 @@
#define BASE_BAUD (PPC4xx_SERCLK_FREQ / 16)
+#define RTC_DVBITS RTC_DVBITS_33KHZ/* 33KHz RTC */
+
#define PPC4xx_MACHINE_NAME"IBM Arctic II"
#endif /* !__ASSEMBLY__ */
linuxppc-commit mailing list
On Fri, 2002-12-13 at 10:35, Tom Rini wrote: > > If you aren't already on the linuxppc-commit at source.mvista.com list, you > > might want to join that. > > And since this is at a possibly non obvious location: > http://source.mvista.com/cgi-bin/mailman/listinfo/linuxppc-commit > > Hopefully PenguinPPC.org will have a link to this somewhere. Actually it's already been linked to for a while (at http://penguinppc.org/dev/kernel.shtml), but I've now made it more obvious. -Hollis -- PowerPC Linux IBM Linux Technology Center ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Move 405LP RTC support from beech.c into ibm405lp.c
On Wed, 2002-12-11 at 21:54, David Gibson wrote: > > The RTC support (written by Todd Poynor) for the Beech is actually in > the 405LP chip itself, not just on the Beech board. As a separate patch (either before or after your move), I'd like to see the following patch committed. The current "reset" code doesn't follow the sequence described in the manual, and doesn't really reset the chip. Until I added this code, the RTC usually would simply not advance. I've tested this thoroughly on Beech (405LP 1.1). Also, the comment makes me curious - why rely on the BIOS to set the right input frequency? It's just one more line of code here (and a #define or two for the various boards). = beech.c 1.8 vs edited = --- 1.8/arch/ppc/platforms/beech.c Mon Nov 11 11:57:56 2002 +++ edited/beech.c Thu Dec 12 10:05:01 2002 @@ -280,10 +280,15 @@ /* Reset the core and ensure it's enabled. We assume only that the BIOS has set the correct frequency. */ - - mtdcr(DCRN_RTC0_WRAP, 0); + + mtdcr(DCRN_RTC0_WRAP, 0); /* toggle NRST & NMR */ mtdcr(DCRN_RTC0_WRAP, 3); - mtdcr(DCRN_RTC0_CR1, mfdcr(DCRN_RTC0_CR1) & 0x7f); + mtdcr(DCRN_RTC0_CR0, 0x60); /* No divider chain, No square wave */ + mtdcr(DCRN_RTC0_CR1, 0x80); /* Disable update cycles /interrupts*/ + mtdcr(DCRN_RTC0_WRAP, 0); /* toggle NRST & NMR */ + mtdcr(DCRN_RTC0_WRAP, 3); + mtdcr(DCRN_RTC0_CR1, mfdcr(DCRN_RTC0_CR1) & 0x7f); /* allow upda tes */ + not_initialized = 0; } -Hollis -- PowerPC Linux IBM Linux Technology Center ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
serial reset?
On Wed, 2002-11-06 at 17:09, David Gibson wrote: > > On Wed, Nov 06, 2002 at 11:13:08AM -0600, Hollis Blanchard wrote: > > > > My current problem is with the UART (and I'm using serial console only, > > so it's problem). When I wake up, I can type commands to my shell and > > see them echoed correctly. However the result of those commands is > > garbled, like so: > > ls > > 1 tm[lc ;u;v 43m > > Sometimes I get the message "ttyS: 1 input overrun(s)". Return > > characters come through as spaces. > > This is a wild guess, but could it be that FIFO mode hasn't been > turned on during the restore. That way individual characters being > echoed (slowly) might work, but faster transfers get garbled, because > the 405 can't keep up with the interrupts. It looks like this was the problem. I'd tried that of course, but this made me double-check it. :) -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
serial reset?
Hi, I'm working on sleep on the 405LP. In one mode the chip is powered down and all state must be saved/restored by software. My current problem is with the UART (and I'm using serial console only, so it's problem). When I wake up, I can type commands to my shell and see them echoed correctly. However the result of those commands is garbled, like so: ls 1 tm[lc ;u;v 43m Sometimes I get the message "ttyS: 1 input overrun(s)". Return characters come through as spaces. I've tried to save/restore the UART registers just like all the others. Unfortunately FCR is write-only, and my attempts have just resulted in no serial activity at all. I've also tried the unregister_serial/register_serial calls to the serial driver (intended for PCMCIA). I can't see how those ever worked -- unregister_serial doesn't reset state->count, which causes register_serial to complain the device is already open. When I hack the driver though, I get the same result though: dead serial. This is a 2.4.17 kernel. Can you think of anything situation that would allow correct character echo but not output? I don't mind going through a full serial initialization if necessary, but it doesn't look like the driver was mutated *ahem* written with this in mind... -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Booting Procedure
On Sun, 2002-11-03 at 00:13, Aman wrote: > > Now I want to debug the kernel. For that I wanted to know the flow. I > got the flow upto certain extent, however I couldn't get the starting > point. Below I have given the flow what I understand. Can you please > tell me if I am right , if not can you please correct me This question would be perfectly suited for the mailing list (cc'ed), where not only would more people have a chance to answer your question, the question and answers would also be recorded in the list archives to help people in the future. It would also allow anyone with free time to answer it, instead of one person who may or may not be busy, and then you'd get the benefit of people correcting each other as needed. > 1. relocate.S [ I am not very sure how the controls come here , can > you please tell me] You must be referring to boot/simple/relocate.S. Control reaches the "relocate" routine from boot/simple/head.S . (I found this using grep.) > 2. From relocate.S , it calls decompress_kernel > 3. it calls _start in [head_440.S] [ I am not very sure how the > controls come here , can you please tell me] Follow the code flow after decompress_kernel; you have less than 10 lines to read! This is the final branch from the bootloader into the kernel (you can tell because the code is no longer under boot/ and instead is under kernel/ ). > 4. _start calls start_kernel and then the kernel comes up. > > I am not getting these files in the source level debugging. Is it > possible to add these files for source level debugging. Most of this is assembly, which RISCWatch does not display. In general though, debuggers are invaluable tools but they do not replace tracing the call flow by hand in small yet complicated codebases like bootloaders. Bootloaders don't need to follow ABI rules about things like stack frames, which a debugger would rely upon to determine backtraces (which I assume is how you were planning on determining the call flow in the first place). -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MTD Driver (denx Linux 2.4.4)
On Thu, 2002-10-31 at 08:37, Flavio Pereira wrote: > > I'm having difficulty in getting the MTD driver working. I'm using a > non-CFI complaint Sharp chip so I have defined CONFIG_MTD_SHARP. However > I cannot locate anywhere in the code where the kernel will call > sharp_probe_init. In any case I forced init_mtd (mtdcore.c) to call > sharp_probe_init and it seems to load the driver okay as I see the > following on my serial console > > JFFS version 1.0, (C) 1999, 2000 Axis Communications AB > JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis > Communications AB. > MTD Sharp chip driver > MTD Sharp chip driver > > Now my question is, do I need to force this driver to load or am I > missing some compile flag? How do I go about partitioning the flash, ie > how does this driver link to a flash map? Those "MTD" lines above, does that mean your driver is being initialized twice? Linux uses ELF tricks for initialization: addresses of all the functions marked __init are put into their own ELF section, and common code somewhere (I forget where) just loops over this section, calling each init function in turn. So you should *not* add an explicit call to your init routine. -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
source-level debugging w/ RISCWatch
--=-RaclAh4Sk1CquNeZPjnZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Someone just asked me about this and I realized other people might find it useful. In your Makefile, CFLAGS_KERNEL = -g -gdwarf rw> load image zImage.treeboot <--- loads zImage onto target rw> load host vmlinux <--- loads debugging info into RISCWatch That's almost all it takes. Unfortunately RISCWatch will try to open unqualified filenames, e.g. "rd.c". So you have to add to your srchpath all the directories you're interested in: rw> srchpath add /home/hollis/src/linux/arch/ppc/platforms rw> srchpath add /home/hollis/src/linux/arch/ppc/kernel rw> srchpath add /home/hollis/src/linux/kernel .. I did this in my startup.cmd file by starting with a `find -type d` and trimming from there. Current (5.0) versions of RISCWatch claim to support dwarf2 which is now the default debug format in gcc 3.x, but gcc 3.x added some extentions that RW doesn't understand, so the load fails. I tried dwarf1 with gcc 3.x, but that fails to compile due to gcc bugs. The recommendation was made to use gcc 2.95 with dwarf2, but that just caused RW to segfault. I'm using dwarf1 with gcc 2.95 and that's working. -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
DBCR0 reset?
Has anyone had problems with hardware breakpoints from external debuggers? I'm using RISCWatch, which sets DBCR0 and IAC1 for me (yes I've verified that). I'm then using 'echo > /proc/sys' to invoke my code. However by the time I get to my sysctl proc handler, DBCR0 has been reset from 0x8081 to 0x0001, hence IAC1 is ignored. I don't see much use of DBCR0, other than initialization and then save during exception prologs and then restore during task restore. Can anyone point me to where it might be reset? -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Changes I would like to get into the 2_4_devel
On Fri, 2002-10-25 at 12:30, Anders Blomdell wrote: > > in arch/ppc/Makefile: >add -D__powerpc__ to CPPFLAGS and CFLAGS (just like it is on kernel.org) > This makes drivers/char/serial.c compile correctly (no more 5 bit > characters) > > in Makefile: >add -D__linux__ to CPPFLAGS > This makes coda.h compile correctly (u_quad_t) > I know that you think I have an incorrectly configured gcc, but I think > that it's a nice feature if the kernel compiles with a gcc that has been > configured according to the 'http://penguinppc.org/embedded/cross-compiling/ > ', even though it warns about gcc-3.x (3.2 generates working code with the > above changes)... This is a handy one-liner for seeing what defines gcc has: echo | powerpc-linux-gcc -E -dM - When I run it with a cross-compiled gcc 2.95.3 *and* 3.2, I see both #define __linux__ 1 #define __powerpc__ 1 The 2.95.3 was compiled with exactly the directions you refer to above. 3.2 was slightly different, but in both cases --target=powerpc-linux . -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC8260 serial on SCC support
Dejan Jovanovic wrote > >Now that I boot I get the following output. >After the 'starting xinetd' is completed sucessfuly, my serial output is stuck. >However I can telnet to my board. >This means that there is some problem with the serial? (maybe 'getc' or >something like this). > I suspect you have not enabled a getty on your serial port (see /etc/inittab). Without that you will not see a login prompt there. -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Riscwatch debugging
On Mon, 2002-10-21 at 07:15, Ralph Blach wrote: > > Try compiling with -dwarf2. We have no problem with symbolic debug with > riscwatch here. > > You will also need to set you srchpath to inclulde the .o file that contain > the debug info Could you be more specific? I've just built a kernel with gcc 3.2 -g (defaults to dwarf2). What must I add to my srchpath so I can debug the whole kernel (not a particular object file)? Currently I have linux/ (for the vmlinux debug info?) and linux/arch/ppc/boot/images (to load the zImage). I've loaded with 'load image zImage.initrd.treeboot', but all the Source windows remain blank. -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems with 2_4_devel & MVME2600 serial interrupts
On Fri, 2002-10-18 at 11:04, Hollis Blanchard wrote: > > On Fri, 2002-10-18 at 10:47, Anders Blomdell wrote: > > > Seems to me that either: > > > a) the pci_intack value is incorrect for your board, in which case you > > > should correct it > > Shure is, question is if it really should be caught from the pci_intack > > register, > > If possible, yes it should (IMHO). There was a thread on linuxppc-dev > about a year ago: > http://lists.linuxppc.org/linuxppc-dev/200112/msg00032.html Oops, this is the right thread: http://lists.linuxppc.org/linuxppc-dev/200111/msg00073.html -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems with 2_4_devel & MVME2600 serial interrupts
On Fri, 2002-10-18 at 10:47, Anders Blomdell wrote: > > Seems to me that either: > > a) the pci_intack value is incorrect for your board, in which case you > > should correct it > Shure is, question is if it really should be caught from the pci_intack > register, If possible, yes it should (IMHO). There was a thread on linuxppc-dev about a year ago: http://lists.linuxppc.org/linuxppc-dev/200112/msg00032.html I think Gabriel's point about hardware testing methods is the best argument, though I also think having hardware figure it out greatly diminishes the chance of software polling race conditions such as those that plagued a few desktop PReP machines for a long time. > as far as I can understand from the MVME2600 doc's, the 8259 > interrupt generates a MPIC-IRQ0, but one has to poll the 8259 to find out > what device it was that generated the interrupt. Yes. Software can do this. The alternative is that some hardware (PHBs) can do it too, which is what you're using if you pass a non-0 address to i8259_init. > Perhaps an extra field in the 'mot_info' (arch/ppc/platforms/prep_pci.c) is > called for? This line in prep_init_IRQ (arch/ppc/platforms/prep_setup.c): > >i8259_init(0xbff0); /* PCI interrupt ack address for MPC105 and 106 > */ > > does not look like a general solution. What you're saying is that you have a PReP machine without a Motorola host bridge? Then yes, that constant will need to be abstracted. -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems with 2_4_devel & MVME2600 serial interrupts
On Fri, 2002-10-18 at 09:59, Anders Blomdell wrote: > > > 2. When the interrupts gets enabled, the system gets an interrupt and > > eventually > >calls i8259_irq, which reads 0xff from pci_intack, which it will > > continue to > >do forever in this loop (do_IRQ, arch/kernel/irq.c): > > A quick (and working, but probably unclean) solution is call > 'i8259_init(intack_addr)' with intack_addr set to zero (instead of the > 0xbff0 from prep_setup.c), thus forcing the interrupt to be polled from > the 8259 controller. Could somebody who understands open_pic (is this a > relative to MPIC?), give me a hint of suitable further reading before I to > try to clean this up? Seems to me that either: a) the pci_intack value is incorrect for your board, in which case you should correct it b) your board's int-ack feature is broken and you'll need to poll -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
860 rtc problem
On Wed, 2002-10-16 at 21:19, leeyang wrote: > > With 'date -s' command it returned time had been changed. > However after a reset,the time go back to 1970's again :-( > > I try with 'hwclock' and it says below: > > bash-2.04# hwclock --debug > hwclock 2.4c/util-linux-2.11f > Using /dev/rtc interface to clock. > Last drift adjustment done at 0 seconds after 1969 > Last calibration done at 0 seconds after 1969 > Hardware clock is on unknown time > Assuming hardware clock is kept in local time. > Waiting for clock tick... > /dev/rtc does not have interrupt functions. Waiting in loop for time from > /dev/rtc to change > ...got clock tick > Time read from Hardware Clock: 1970/01/09 21:28:28 > Hw clock time : 1970/01/09 21:28:28 = 786508 seconds since 1969 > Fri Jan 9 21:28:28 1970 -0.188839 seconds `hwclock` with no arguments seems to be the same as `hwclock --show`. I would recommend `hwclock -w`. -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
bitkeeper
On Mon, 14 Oct 2002, Cameron, Steve wrote: > > So, I was wondering if there are any plans to say, mirror > the development linux powerpc bitkeeper tree as a tar.bz2 > on a more regular basis, like the regular linux kernel > development team does? Or perhaps someone is already > doing that, and I just don't know about it? MontaVista already provides rsync access to the PPC bk trees. See http://penguinppc.org/dev/kernel.shtml for more details. -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cross-compiler and stdarg.h
On Thu, 10 Oct 2002, D'Abbraccio Joe-ljd015 wrote: > > When I build the kernel using the ELDK I get the following failure: > > > ppc_82xx-gcc -D__KERNEL__ -I/usr/opt/kernels/linuxppc_2_4_devel/include -Wall > -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common > -fomit-frame-pointer -I/usr/opt/kernels/linuxppc_2_4_devel/arch/ppc > -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple > -mstring -nostdinc -iwithprefix include -DKBUILD_BASENAME=sched > -fno-omit-frame-pointer -c -o sched.o sched.c > In file included from > /usr/opt/kernels/linuxppc_2_4_devel/include/linux/wait.h:13, > from > /usr/opt/kernels/linuxppc_2_4_devel/include/linux/fs.h:12, > from > /usr/opt/kernels/linuxppc_2_4_devel/include/linux/capability.h:17, > from > /usr/opt/kernels/linuxppc_2_4_devel/include/linux/binfmts.h:5, > from > /usr/opt/kernels/linuxppc_2_4_devel/include/linux/sched.h:9, > from > /usr/opt/kernels/linuxppc_2_4_devel/include/linux/mm.h:4, > from sched.c:23: > /usr/opt/kernels/linuxppc_2_4_devel/include/linux/kernel.h:10: stdarg.h: No > such file or directory > < > > Where is stdarg.h expected to come from if not from stdinc (i.e. > -nostdinc). I don't believe there is one in kernel distribution. I just had this problem and I'm embarassed to say I'm not quite sure what caused it. I was building on a ppc64 box, but when I switched from the ppc32 "cross-compiler" to the native toolchain (which is ppc32) the problem went away. Your cross-compiler includes this file in /lib/gcc-lib/powerpc-linux//include/ . -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Anyone built a PPC cross compiler on debian?
On Wednesday 02 October 2002 22:54, Erik Christiansen wrote: >Penguinppc.org's "Cross Development mini-howto for PPC Linux" failed > to build on my x86 debian woody host, due to an autoconf bug. (Thanks to > Hollis Blanchard for identifying this.) [snip] >While I toss a coin to choose between trying to build binutils in a > manual hack, or dealing with RPMs on debian, is there another option > that should be considered? Don't misunderstand... yes there's a configure.in bug, but it's only triggered by you missing something you need (this is frequently i18n stuff). So another option for you is to install the missing package. -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Is it binutils-2.13.90.0.4 or is it me?
On Tuesday 01 October 2002 20:03, Erik Christiansen wrote:
>Following the mini-howto on penguinppc.org, I started with compilation
> of binutils.
>
>./configure --target=powerpc-linux finished in a happy frame of mind,
> but make spat the dummy, flagging errors on some rather elusive
> scripting:
>
> cd .. \
> && CONFIG_FILES=po/Makefile.in:po/Make-in \
> CONFIG_HEADERS= /bin/sh ./config.status
> creating po/Makefile.in
> make[3]: Leaving directory `/usr/local/src/binutils-2.13.90.0.4/bfd/po'
> make[3]: Entering directory `/usr/local/src/binutils-2.13.90.0.4/bfd/po'
> file=./`echo sv | sed 's,.*/,,'`.gmo \
> && rm -f $file && PATH=../src:$PATH no -o $file sv.po
> /bin/sh: no: command not found
>
>Now, grep -r 'no -o' /usr/local/src/binutils-2.13.90.0.4/bfd/po draws
> a blank, so before looking further for where it could be fixed, I
> thought I'd ask whether going back a version or two might provide
> smoother sailing?
This typically means someone did their autoconf wrong. You're missing some
feature ("Checking for /bin/foo... no") but the script doesn't actually check
for an error, and uses 'no' where it obviously shouldn't.
It is a bug; you should submit a bug report once you figure out what app it
is.
-Hollis
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
601 BAT sizes
On Wed, 2002-08-28 at 09:35, Allen Curtis wrote: > > > I don't believe this is correct for all PowerPC processors that have BATs. > > Can you verify this and ensure it works on everything? I know 601s have > > different sized BATs, and the caller of this function really needs to know > > what they are doing to ensure this works correctly. > > It is correct according to the comments for setbat(), I will double check. 601 BATs only do 128KiB to 8 MiB. In fact setbat special-cases 601 and limits it to 8MiB. I believe updating the setbat comment would be a good idea... -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
IBM 440GP 36-bit addressing
On Sat, 2002-08-24 at 02:05, Vishwanath wrote: > > By going through the code, I understood that ioremap64() is used for mapping > the 36-bit real address onto 32-bit effective address space. How this > mapping information is conveyed to user applications ? I don't understand the question. Do you mean "how does userspace know what the kernel has ioremapped"? I don't think it does. Do you mean "how can userspace map in a 36-bit real address"? The usual (32-bit) way is to mmap(/dev/mem). I don't know if that will work with 36-bit addresses. > If I am writing assembly instructions to access 440GP registers, do I have > to pass 36-bit real address or 32-bit effective address ? Do you mean a memory-mapped register, i.e. an on-chip peripheral like the UART? If so, that's what we've been talking about. You must map the 36-bit real address into your 32-bit effective address space, then access the effective address. > Physical address map of 440GP provides information only about Real > addresses. How can I convert these real addresses onto effective addresses > ? Do I have to write a TLB entry regarding my addresses ? Exactly, that's what I mean by "mapping". Of course, some TLB entries may already have been set up for you by the kernel or firmware. Whatever the case, you need to make sure there is a TLB entry in place. -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
IBM 440GP 36-bit addressing
On Fri, 2002-08-23 at 10:00, Vishwanath wrote: > > I am new to PPC Linux. I am working on IBM 440 GP board. I am using > MontaVista Linux source code. I didn't understand how 36-bit addressing is > taken care in this code. If an application has to access the a memory > location in SDRAM of 440 GP or its internal peripheral registers, whether it > has to pass 36-bit address or normal 32-bit address. It's a 36-bit real address space, but 32-bit effective (aka "virtual"). Applications, which run entirely in effective address space, have no reason to think about such things and require no modification. The kernel has to care about the real address space, mostly when you want to ioremap (all the on-chip peripheral addresses are higher than 4GB as I recall) a 36-bit real address to a 32-bit effective address so you can use it in the kernel (which also runs in effective mode). -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
__cli on 4xx - MSR:CE?
On Tue, 2002-07-30 at 19:52, David Gibson wrote: > > If critical interrupts are disabled everywhere that normal interrupts > are disabled, there seems little point in having them. Sure, I understand that. Will there then be a "__crit_cli" for when you really don't want exceptions of any kind? And __save_and_crit_cli ? -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
__cli on 4xx - MSR:CE?
Shouldn't __cli on 4xx disable the MSR CE bit as well as EE? -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
