annamaya wrote?
> lists. And yes, forgot to say hi to Wolfgang Denk,
> another one of my mentors. Hey Denk.
>
I also have the same feeling as you. :-)
So why not feed back your work to DENX? There is no
other appropriate public place to receive the 82xx and
8xx 2.4 patch, I am afraid.
BTW, I
In message <20041014181059.21986.qmail at web53803.mail.yahoo.com> you wrote:
> Thanks again. I am glad to be back on the mailing
> lists. And yes, forgot to say hi to Wolfgang Denk,
> another one of my mentors. Hey Denk.
Hello!
> And what's the story on lists.linuxppc.org. Will they
> ever retri
On Oct 14, 2004, at 11:53 AM, annamaya wrote:
> I cant believe I was stupid enough to beleive that the
> user's manual of an eval board was giving me the
> correct information.
Well, you have to start somewhere. Good job
debugging, you get major points for that! :-)
-- Dan
Thanks again. I am glad to be back on the mailing
lists. And yes, forgot to say hi to Wolfgang Denk,
another one of my mentors. Hey Denk.
And what's the story on lists.linuxppc.org. Will they
ever retrieve the archives?
--- Dan Malek wrote:
>
> On Oct 14, 2004, at 11:53 AM, annamaya wrote:
>
I cant believe I was stupid enough to beleive that the
user's manual of an eval board was giving me the
correct information.
The problem turned out to be that the FCC controllers
were not assigned to the ports that the manual stated.
They were switched. I was configuring the wrong FCC
controllers
On Oct 13, 2004, at 5:23 PM, annamaya wrote:
> I verified that the TX and RX clock signals are
> correct and the CMXFCR route register is programmed
> correctly for FCC2. I still see TX timeout errors. I
> am stumped. :-(
Do you have the FCC MAC set up properly for
full or half duplex? If you d
On Oct 13, 2004, at 3:21 PM, annamaya wrote:
> I looked at the driver again and it looks like the TX
> and RX clock signals are board specific. I will also
> have to program the CMXFCR clock route register with
> the appropriate clocks. Am I on the right track here?
Yep. :-)
-- Dan
I verified that the TX and RX clock signals are
correct and the CMXFCR route register is programmed
correctly for FCC2. I still see TX timeout errors. I
am stumped. :-(
--- Dan Malek wrote:
>
> On Oct 13, 2004, at 3:21 PM, annamaya wrote:
>
> > I looked at the driver again and it looks like th
I looked at the driver again and it looks like the TX
and RX clock signals are board specific. I will also
have to program the CMXFCR clock route register with
the appropriate clocks. Am I on the right track here?
--- annamaya wrote:
> I was able to use the same driver on a PQ2-FADS
> board
> wi
On Oct 13, 2004, at 10:49 AM, annamaya wrote:
> . But my driver doesn't work and complains
> about a TX timeout. I am sure I am missing something.
> Can you suggest something that I could try?
You are going to have to track down the clock and
control signals for the FCC and make sure they ar
I was able to use the same driver on a PQ2-FADS board
with an MPC8275 processor. Are you telling me that
some of these pins are board specific? Thanks for your
help.
--- Dan Malek wrote:
>
> On Oct 13, 2004, at 10:49 AM, annamaya wrote:
>
> > . But my driver doesn't work and complains
> >
Thanks for the reply Dan. Just before I got your mail,
I was going through the fcc ethernet driver from
mvista and I noticed the BCSR hack code to make the
PHY work on an EP8260. I went back to the manual for
the EP8280 and realized that they did something
similar on this board, just as you guessed
On Oct 12, 2004, at 5:02 PM, annamaya wrote:
> I am now trying to do an NFS mount of the root file
> system. Looks like the EP8280 uses LXT971A PHY device.
I have one of their first 8260 boards that I used to do
the initial Linux port long ago. At that time, they had
some weird CPLD implementat
My problem had to do with the fact that I was not
sending my flash device information in the bd_info
structure and therefore, jffs2 was crapping out. Once
I turned include this info in bd_info, the kernel came
up just fine and started to boot.
I am now trying to do an NFS mount of the root file
sy
annamaya wrote:
> now able to see the "relocation" messages by zImage
> and it now halts with the message "Now booting the
> kernel". I see that it is now hung in some delay
[snip]
> Linux/PPC load: root=/dev/nfs rw ip=on
Well, I guess there is sth wrong in your parameter
passing to kernel. Add "
I am using the Linux Kernel 2.4.24-pre2. I included
support for this board and created an embed_config()
routine to pass in the correct board information. I am
now able to see the "relocation" messages by zImage
and it now halts with the message "Now booting the
kernel". I see that it is now hung i
On Oct 11, 2004, at 1:50 PM, annamaya wrote:
> I loaded a zImage into address 0x10 in RAM and
> verified that this was indeed an ELF file. I then said
> "go 0x100040" which would start executing the code
> after skipping the 64 bytes of ELF header. But this is
> what I see happen.
Two proble
On Oct 11, 2004, at 1:33 PM, annamaya wrote:
> I will try the zImage trick
It's not a trick nor magic :-) It's required for use
with these boards because..
> ...but I just wanted to know
> if the assumption here is that the kernel already
> understands the EEPROM data format to construct
>
On Mon, Oct 11, 2004 at 02:18:59PM -0700, annamaya wrote:
> I do not have any other logs when this happens since I
> dont have any serial output when the failure happens.
> I am trying to do this on a EP8280 eval board. Has
> someone already included support for this board in the
> Kernel? Thank y
I do not have any other logs when this happens since I
dont have any serial output when the failure happens.
I am trying to do this on a EP8280 eval board. Has
someone already included support for this board in the
Kernel? Thank you.
--- Tom Rini wrote:
> On Mon, Oct 11, 2004 at 11:38:28AM -0700
On Oct 11, 2004, at 12:04 PM, annamaya wrote:
> I am trying to boot a linux kernel using a PlanetCore
> BootLoader on an embedded planet board. I am used to
> always using U-Boot for my Kernel booting needs. I am
> not sure how to get this going on a PlanetCore boot
> loader.
You need to build a
On Mon, Oct 11, 2004 at 11:38:28AM -0700, annamaya wrote:
> Oops! Thanks for pointing that blooper. I am so used
> to dealing with the U-Boot header of 64 bytes that I
> misread the ELF header size as 64 bytes instead of 64
> KBytes.
>
> Anyways, it looks like I am much farther that I have
> eve
Oops! Thanks for pointing that blooper. I am so used
to dealing with the U-Boot header of 64 bytes that I
misread the ELF header size as 64 bytes instead of 64
KBytes.
Anyways, it looks like I am much farther that I have
ever been before. Now, I see that the PC is stuck at
some address that I am
On Mon, Oct 11, 2004 at 10:50:54AM -0700, annamaya wrote:
> I loaded a zImage into address 0x10 in RAM and
> verified that this was indeed an ELF file. I then said
> "go 0x100040" which would start executing the code
> after skipping the 64 bytes of ELF header. But this is
> what I see happen.
I loaded a zImage into address 0x10 in RAM and
verified that this was indeed an ELF file. I then said
"go 0x100040" which would start executing the code
after skipping the 64 bytes of ELF header. But this is
what I see happen.
BDI>info
Target CPU: MPC8280/8220/5200 (Zeppo)
Tar
Dan,
First let me thank you for still being around to
answer questions for people like me. You helped me out
a lot a few years ago when I was just starting to work
on all the embedded stuff. I am glad you are still
helping everyone else.
I will try the zImage trick but I just wanted to know
if the
I am trying to boot a linux kernel using a PlanetCore
BootLoader on an embedded planet board. I am used to
always using U-Boot for my Kernel booting needs. I am
not sure how to get this going on a PlanetCore boot
loader. I am sure someone has gone through this before
and I was trying to find inform
27 matches
Mail list logo
