Matt Gessner wrote:
> I had ioremap'd it, and put va's and pa's where each belonged
> (va's for the kernel's tracking stuff and pa's for the CPM stuff).
The va/pa macros are not going to work on Local memory addresses.
You have to explicitly compute these addresses.
I have a board with some lo
Yep, it has an __init for me too. Interesting.
Good eyes!
mike
At 04:59 PM 6/27/00, Lucinda Schafer wrote:
>I noticed an __init in front of m8xx_ide_init_hwif_ports.
>
>According to init.h:
>
>/* These macros are used to mark some functions or
> * initialized data (doesn't apply to uninitiali
Classic linux kernel like 2.2.16 works well and reliably on PPC 7xx
processors.
The Monta Vista kernel is only tested on 8xx processor, and the 7xx support
is probably broken.
Patrick LERDA
> -Message d'origine-
> De: Tom Roberts [SMTP:tjroberts at lucent.com]
> Date: mardi 27 juin 200
Matt Gessner wrote:
>
> Hello list,
>
> Has anyone done anything with mapping local bus memory
> so that it can be used for FCC BD's and buffers?
>
> I **thought** I had it right, but my driver eventually
> causes the machine to hang (EST SBC8260).
>
> I had ioremap'd it, and put va's and pa's whe
I noticed an __init in front of m8xx_ide_init_hwif_ports.
According to init.h:
/* These macros are used to mark some functions or
* initialized data (doesn't apply to uninitialized data)
* as `initialization' functions. The kernel can take this
* as hint that the function is used only during
NIP is c00def58 (m8xx_ide_init_hwif_ports)
LR is c0002da4 (inside ide_init_hwif_ports)
I gather that LR is the place you were called from and NIP is the next
instruction, in which case both of these seem to be correct.
mike
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc
Hi,
Jerry Van Baren wrote:
>
> Jon Diekema and I tried Wolfgang's "load" flag hint with the EST JTAG
> debugger and were unsuccessful. We were unable to use objcopy to make
> the extra sections loadable. We are guessing that you have to set the
> loadable flag, but you also have to label the se
It is unfortunate that there apparently is no standard. The only item
that I'm concerned with at the moment is the 8260 IMMR which is
readable but only if you know where it is first, in which case there is
no need to read it. :-(
Due to (a) laziness and (b) heredity (the board's, not mine), the
Jerry Van Baren wrote:
> It would be better to not jump to the reset vector on a warm
> start.
Yes, but there isn't any standard among the 8xx boot roms.
This seems to work on all of the boards I have ever tested. If
it doesn't work for you, let's discuss it and find something that
does.
It would be better to not jump to the reset vector on a warm
start. Often there is hardware configuration issues with rerunning all
the reset code - the primary one is that the IMMR quite likely is in a
different location than the power up default value.
I've seen two conventions. The one I've
Correction: C0002D7C is in fact ide_init_hwif_ports.
This makes much more sense.
But it still doesn't explain what could cause that piece of kernel code to
be zeroed out. Any suggestions would be greatly appreciated.
Sorry for the confusion,
mike
** Sent via the linuxppc-embedded mail list. S
OK, I have a backtrace and added some prink's and LED outputs at the
beginning and ends of interesting functions, and here is what I think is
going on:
the PCMCIA stuff recognizes the card as an ATA flashdisk and calls
ide_register() to set things up.
ide_register() calls ide_init_hwif_ports() to
Hi Michael,
What are the values of the NIP and LR at the time of the kernel panic?
We, too, are still battling the kernel panic: Kernel Mode Software FPU
Emulation problem with our MPC823 (custom) board.
We are not using PCMCIA or IDE support. However we are using AX.25, which
most (all??) others
Dan Malek wrote:
> Here is the first installment.
Let's try this again...I will actually attach something
this time. I am travelling and don't have access to a system
or enought documentation to attempt checkstop/reset.
-- Dan
-- next part --
--- linux.old/
Hmmm. I'm not exactly sure which 'kind' of reset I should be using.
What I'm trying to accomplish is getting "init 6" or "reboot" to work as
expected. I.e. JLAPC (Just like a PC ;-)
I'd like the reset to result a reset to the RPXU2 which restarts my kernel
via 'autoboot'. Since the 'reset' c
Mark S. Mathews wrote:
> We're using the mvista 2.2.13-3 kernel sources and I'd like to add a
> software reboot capability.
Here is the first installment. It will allow commands that use
the reboot system call (like 'reboot') to properly jump into the
system reset vector. If you want to write
Hello,
I'm having trouble getting this combination to work.
Has anyone had success?
I tried to follow the basic outline of the scc enet driver,
but of course there are some significant differences.
I think I'm tripping on VA <-> PA stuff, but I'm not sure,
as the machine just dies.
I'm using th
Tom Roberts wrote:
> How about on an embedded MPC750 or MPC7400? Before joining this
> list I discovered Kernel version 2.2.15 on Yellowdog and have been
> using that.
That should work. The question was directed toward 8xx processors,
so I thought I would answer that.
> There are zillions of r
Hello list,
Has anyone done anything with mapping local bus memory
so that it can be used for FCC BD's and buffers?
I **thought** I had it right, but my driver eventually
causes the machine to hang (EST SBC8260).
I had ioremap'd it, and put va's and pa's where each belonged
(va's for the kernel
Dan Malek wrote:
> You shouldn't be using 2.2.15 with 8xx. I am not going to discuss
> the history right now, but the only reliable verion of 2.2.xx Linux
> is the 2.2.13 version on the MontaVista Web site (www.mvista.com).
How about on an embedded MPC750 or MPC7400? Before joining this
list I d
I have the code from Monta Vista on my prietary board,
I find
it get stuck in the open("dev/console",..) in fucntion
init()
in init/main.c, just before to start the shell from
ramdisk.
So I put a printk("ppc405_uic_enable\n") in function
ppc405_uic_enable()
and a printk("ppc405_uic_disable_and_ack
On Mon, 26 Jun 2000 08:48:36 -0400, Jerry Van Baren
writes:
>* It isn't how everybody uses the load: everybody just strips the elf
>header (pastes on a proprietary(?) header) and uses it as as a raw
>binary image
Here's one example of how people use the load ...
I use the "libbfd" library (gen
22 matches
Mail list logo