* Re: MPC82xx -- DPRAM1
From: Dan Malek @ 2004-11-18 23:11 UTC (permalink / raw)
To: morten.banzon; +Cc: linuxppc-embedded
In-Reply-To: <OF39E98ED9.64FBC87A-ONC1256F50.006BC66A-C1256F50.006EA31B@axxessit.no>
On Nov 18, 2004, at 3:08 PM, morten.banzon@axxessit.no wrote:
> If you know the reason to why it is "a very bad idea" to relocate these
> resources within dpram1 I am very curious to learn. On the other hand
> if
> you do not know, then please refrain from giving such a stupid answer.
As you have discovered, there are many dependencies on the
configuration of the cpm smc from the boot rom to bootloaders to
the Linux kernel itself. It's a bad idea to be changing one of these
without changing all of the others to match .... and then you end
up with a custom piece of software that you have to constantly
maintain. If you make it configurable, then you end up with even
more confusion when people mismatch the configurations on
a board.
There isn't any reason to change the current SMC buffering configuration
on the CPM2 (and future) devices. If you like change for the sake
of change, then go ahead and do it. We answered the questions
you asked and specifically said the changes you were making at
the time weren't a good idea. Just because you didn't agree
doesn't make it a stupid response, especially since it's pretty easy
to figure out on your own from looking at the code.
Thanks.
-- Dan
^ permalink raw reply
* Re: Lite5200 FEC Driver on linux 2.6 broken? (fixed again)
From: roger blofeld @ 2004-11-18 20:22 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: tnt, linuxppc-embedded
In-Reply-To: <20041116201654.GA3088@xyzzy>
Adding a call
flush_dcache_range((u32)skb->data, (u32)skb->data + skb->len);
just before spin_lock_irq() in fec_hard_start_xmit() removes the
remaining transmission checksum errors for me.
-rb
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
^ permalink raw reply
* Large PCI region mapping 8272
From: Milligan, Keath @ 2004-11-18 20:05 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I am having trouble getting PCI devices mapped correctly under Linux 2.4.22
running on an MPC8272ADS evaluation board.
I have multiple PCI-attached devices with a total of 512MB of prefetchable
memory and about 200MB of non-prefetchable memory address spaces in various
block sizes. All of the devices are behind a PCI-to-PCI bridge that is
plugged into the ADS.
At this stage in my project, these devices are initializing themselves to
base addresses that need to be moved when Linux boots on the 8272. The
problem I am having is that Linux is trying to remap everything, but is
unable to allocate regions for everything, so I end up with most of the
devices mapped to the same (invalid) address.
I've tried hacking the kernel PCI initialization to manually set all the
base addresses, but it seems to be ignoring that for the most part.
Could someone point me in the right direction to getting everything
initialized and mapped correctly?
Thanks
^ permalink raw reply
* Re: MPC82xx -- DPRAM1
From: morten.banzon @ 2004-11-18 20:08 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
By modifying the kernel I meant modifying the cpm uart driver. If that was
not clear I appologise.
I do not how much of this thread you have been reading, but if you know of
a way to relocate the resources in the dpram1 used by the cpm uart (smc1
in this case) other than what is suggested in the previous mail I am eager
to hear from you.
Since the contents of the arch/ppc/boot are not compiled, and certainly
not the arch/ppc/boot/simple/m8260_tty.c, then there is absolutely no code
in cpm_uart_core.c or cpm_uart_cpm2.c that configure the SMC1_BASE
register, or the SMC2_BASE register for that matter, found at offset
0x87FC and 0x88FC respectively. Hence, there is no way for the cpm/smc
hardware to know were to look for the buffer descriptor tables, hence
there is no wayt to get a working console on the smc1 unless the
bootloader configure this identical to what the cpm uart driver within the
kernel expect. I think I have proven that too by first changing the
necessary constants in arch/asm-ppc/cpm2.h, which causes the console to
die as soon as the linux kernel take over control after the bootloader.
Modifying the u-boot to reflect the modifications done in cpm2.h make the
whole thing work nicely again.
I agree with you that each driver is supposed to perform all required
initialization steps itself, but that is not the case for the cpm_uart smc
driver. This driver consists as far as I can see of two files;
cpm_uart_cpm2.c and cpm_uart_core.c, and the header files. I might be
wrong ofcourse claiming that this driver is not able to get off the ground
without help from a bootloader, and any such explaninations are most
welcome. I sincerely want to understand this.
Your "Read the code" commet is the best answer to these queries I have
seen so far. I guess you and Dan Malek understand something that is not
possible to read from the code. Well, I have relocated both the first 128
bytes of the dpram1 and the buffer descriptors for the smc1 driver.
Similar thing is done wiht the i2c driver and so far, just for a few hours
though, they are working happily.
If you know the reason to why it is "a very bad idea" to relocate these
resources within dpram1 I am very curious to learn. On the other hand if
you do not know, then please refrain from giving such a stupid answer.
-- Morten
Wolfgang Denk <wd@denx.de>
Sent by: wd@denx.de
18.11.2004 18:38
To: morten.banzon@axxessit.no
cc: linuxppc-embedded@ozlabs.org
Subject: Re: MPC82xx -- DPRAM1
In message
<OFD0B78DE0.9222EE0F-ONC1256F50.003811B2-C1256F50.003B80FF@axxessit.no>
you wrote:
>
> I do not understand all the intricacies of what happens regarding
hardware
> configuration during the eraly stages of booting linux, but I conclude
> that when making a uImage one have to modify u-boot and the kernel if
one
> want to relocate the usage of dpram1 by the cpm uart driver. This might
> have been obvious to most of you, but I was lost on this issue.
There is no need to modify U-Boot nor the kernel. Each driver is
supposed to perform all required initialization steps itself. It must
not make any assumptions about it's previous state except that it's
"harmless", i. e. interrupts are disabled etc. when the driver is
starting.
> A mystery is why Dan Malek said it was a "very bad idea" to relocate the
> smc buffer descriptors to anohter part of dpram1.
> Maybe I will understand that one day too.
Read the code.
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
Vulcans believe peace should not depend on force.
-- Amanda, "Journey to Babel", stardate 3842.3
^ permalink raw reply
* Re: Ethernet on 5200 is using DMA?
From: Mark Chambers @ 2004-11-18 17:48 UTC (permalink / raw)
To: Iñigo Lopez Barranco, linuxppc-embedded
In-Reply-To: <42A622EB18325843894BB8E1040E3DF5022830@sinaexchf>
I don't think it's possible to NOT use DMA on a 5200. If your link
is 100Mbps and you are putting out something close to that then
90% is not unreasonable. There are still memory copies involved.
Where is it getting the large file from? Maybe IDE is a bottleneck.
Mark Chambers
wvcomputronics.com
----- Original Message -----
From: "Iñigo Lopez Barranco" <ilopez@albatros-sl.es>
To: <linuxppc-embedded@ozlabs.org>
Sent: Thursday, November 18, 2004 11:55 AM
Subject: Ethernet on 5200 is using DMA?
Hi. I'm using linuxppc_2_4_devel from Denx CVS on a Lite5200 board.
When doing "put" of a large file to a ftp server, ftp eats all the CPU
available (90%+). I suspect it's not using DMA for the ethernet. Is this
right?
Thanks in advance.
Iñigo
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: MPC82xx -- DPRAM1
From: Wolfgang Denk @ 2004-11-18 17:38 UTC (permalink / raw)
To: morten.banzon; +Cc: linuxppc-embedded
In-Reply-To: <OFD0B78DE0.9222EE0F-ONC1256F50.003811B2-C1256F50.003B80FF@axxessit.no>
In message <OFD0B78DE0.9222EE0F-ONC1256F50.003811B2-C1256F50.003B80FF@axxessit.no> you wrote:
>
> I do not understand all the intricacies of what happens regarding hardware
> configuration during the eraly stages of booting linux, but I conclude
> that when making a uImage one have to modify u-boot and the kernel if one
> want to relocate the usage of dpram1 by the cpm uart driver. This might
> have been obvious to most of you, but I was lost on this issue.
There is no need to modify U-Boot nor the kernel. Each driver is
supposed to perform all required initialization steps itself. It must
not make any assumptions about it's previous state except that it's
"harmless", i. e. interrupts are disabled etc. when the driver is
starting.
> A mystery is why Dan Malek said it was a "very bad idea" to relocate the
> smc buffer descriptors to anohter part of dpram1.
> Maybe I will understand that one day too.
Read the code.
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
Vulcans believe peace should not depend on force.
-- Amanda, "Journey to Babel", stardate 3842.3
^ permalink raw reply
* Re: kernel 2.6.10-rc2 - Embedded MPC8xx - processor option gone !?
From: Dan Malek @ 2004-11-18 17:40 UTC (permalink / raw)
To: Guillaume Autran; +Cc: linuxppc-embedded
In-Reply-To: <419CCC85.8080003@mrv.com>
On Nov 18, 2004, at 11:23 AM, Guillaume Autran wrote:
> Is anyone working on a fix already ?
In my spare time, which I have little of right now.
I know the symptom, as Tom mentioned, but not the cause.
-- Dan
^ permalink raw reply
* Ethernet on 5200 is using DMA?
From: Iñigo Lopez Barranco @ 2004-11-18 16:55 UTC (permalink / raw)
To: linuxppc-embedded
Hi. I'm using linuxppc_2_4_devel from Denx CVS on a Lite5200 board.
When doing "put" of a large file to a ftp server, ftp eats all the CPU =
available (90%+). I suspect it's not using DMA for the ethernet. Is this =
right?
Thanks in advance.
I=F1igo
^ permalink raw reply
* Re: kernel 2.6.10-rc2 - Embedded MPC8xx - processor option gone !?
From: Tom Rini @ 2004-11-18 16:18 UTC (permalink / raw)
To: Guillaume Autran; +Cc: linuxppc-embedded
In-Reply-To: <419CCC85.8080003@mrv.com>
On Thu, Nov 18, 2004 at 11:23:33AM -0500, Guillaume Autran wrote:
> Is anyone working on a fix already ?
Not actively. The problem has been described on the list a few times
(it seems like there's a stale TLB entry).
> Will the MPC8xx support be functionnal for 2.6.10 ?
Most likely no.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: kernel 2.6.10-rc2 - Embedded MPC8xx - processor option gone !?
From: Guillaume Autran @ 2004-11-18 16:23 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
In-Reply-To: <20041118160946.GD12054@smtp.west.cox.net>
[-- Attachment #1: Type: text/plain, Size: 738 bytes --]
Is anyone working on a fix already ?
Will the MPC8xx support be functionnal for 2.6.10 ?
Thanks.
Guillaume.
Tom Rini wrote:
>On Thu, Nov 18, 2004 at 10:10:31AM -0500, Guillaume Autran wrote:
>
>
>
>>Does anyone know why the option "8xx" in the "Processor Type" screen of
>>the menuconfig is gone ?
>>
>>
>
>It's not gone, it just depends on CONFIG_BROKEN. A lot of code was
>finally synced up, but since it's not fully functional (it's the same
>state as was in linuxppc-2.5), it requires CONFIG_BROKEN to be set.
>
>
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
[-- Attachment #2: Type: text/html, Size: 1300 bytes --]
^ permalink raw reply
* Re: kernel 2.6.10-rc2 - Embedded MPC8xx - processor option gone !?
From: Tom Rini @ 2004-11-18 16:09 UTC (permalink / raw)
To: Guillaume Autran; +Cc: linuxppc-embedded
In-Reply-To: <419CBB67.1070301@mrv.com>
On Thu, Nov 18, 2004 at 10:10:31AM -0500, Guillaume Autran wrote:
> Does anyone know why the option "8xx" in the "Processor Type" screen of
> the menuconfig is gone ?
It's not gone, it just depends on CONFIG_BROKEN. A lot of code was
finally synced up, but since it's not fully functional (it's the same
state as was in linuxppc-2.5), it requires CONFIG_BROKEN to be set.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [patch] Solves syslib/m8260_setup.c ROOT_DEV problem
From: Tom Rini @ 2004-11-18 16:03 UTC (permalink / raw)
To: alebas; +Cc: linuxppc-embedded
In-Reply-To: <1100264953.4194b5f9eab0f@webmail.televes.com:443>
On Fri, Nov 12, 2004 at 02:09:13PM +0100, alebas@televes.com wrote:
> Hi,
>
> This patch applies against head versions of both linuxppc-2.5 in ppc.bkbits.net
> and linux-2.5 in linux.bkbits.net
>
> I don't now if this has been corrected in some other tree.
>
> The patch corrects the following error during compilation
>
> LD arch/ppc/lib/built-in.o
> CC arch/ppc/syslib/m8260_setup.o
> arch/ppc/syslib/m8260_setup.c: In function `m8260_setup_arch':
> arch/ppc/syslib/m8260_setup.c:56: `ROOT_DEV' undeclared (first use in this
> function)
> arch/ppc/syslib/m8260_setup.c:56: (Each undeclared identifier is reported only
> once
> arch/ppc/syslib/m8260_setup.c:56: for each function it appears in.)
> arch/ppc/syslib/m8260_setup.c:56: `Root_RAM0' undeclared (first use in this
> function)
> arch/ppc/syslib/m8260_setup.c: In function `m8260_show_cpuinfo':
> arch/ppc/syslib/m8260_setup.c:149: warning: unsigned int format, long unsigned
> int arg (arg 5)
> arch/ppc/syslib/m8260_setup.c:149: warning: int format, long unsigned int arg
> (arg 6)
> arch/ppc/syslib/m8260_setup.c:149: warning: unsigned int format, long unsigned
> int arg (arg 7)
> arch/ppc/syslib/m8260_setup.c:149: warning: unsigned int format, long unsigned
> int arg (arg 8)
> arch/ppc/syslib/m8260_setup.c:149: warning: unsigned int format, long unsigned
> int arg (arg 9)
> make[1]: *** [arch/ppc/syslib/m8260_setup.o] Error 1
> make: *** [arch/ppc/syslib] Error 2
>
> Here, arch was ppc and configuration was ads8272_defconfig.
I'll push something similar, thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* kernel 2.6.10-rc2 - Embedded MPC8xx - processor option gone !?
From: Guillaume Autran @ 2004-11-18 15:10 UTC (permalink / raw)
To: linuxppc-embedded
Does anyone know why the option "8xx" in the "Processor Type" screen of
the menuconfig is gone ?
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
^ permalink raw reply
* Re: 2.4 -> 2.6: problem probing PCI
From: Marc Leeman @ 2004-11-18 13:28 UTC (permalink / raw)
To: Linux PPC Mailing List
In-Reply-To: <1f729c48041117075151960f69@mail.gmail.com>
> Anyway, insights are welcome, I'm still investigating...
Found it, I used the wrong arc/ppc/platforms file after too zealous
cleanup of the code. I need some final testing but it looks like this
will be the only file that needs update (considering the PCI mapping
and scanning).
--=20
ash nazg durbatul=FBk, ash nazg gimbatul,
ash nazg thrakatul=FBk agh burzum-ishi krimpatul
^ permalink raw reply
* mpc8272ads lowboot ... I got it
From: alebas @ 2004-11-18 11:32 UTC (permalink / raw)
To: VanBaren, Gerald (AGRE); +Cc: u-boot-users, linuxppc-embedded
Hi all,
Wooouh, this morning I was sleeping.
I have post the mail to the wrong list and with the wrong Subject (sorry
to those in the linuxppc-embedded list).
Well, I finally got uboot-lowboot working. The problem was in the CS6PC
bits (24-25) in the HRCW (i think these are the same than CS10PC bits in
the PQ2ADS). This must be configured as CS6 (00), not as BCTL1 (01).
So, the HRCW for lowboot in the MPC8272ADS i have used is 0x0E_74_B2_0A.
Now it works great. Thanks Gerald.
Will the patch finally include the different HRCWs? At least, this
should be documented, shouldn't it?
Alex
^ permalink raw reply
* Re: MPC82xx -- DPRAM1
From: morten.banzon @ 2004-11-18 10:49 UTC (permalink / raw)
To: Mark Chambers; +Cc: linuxppc-embedded
Thanks again for your reply to my queries.
I did not know that arch/ppc/boot stuff and u-boot were mutually
exclusive. Thanks for clarifying that.
In fact I have not been considering what is left out when you make a
uImage as opposed to zImage, obviously I have som styding to do here.
I do not understand all the intricacies of what happens regarding hardware
configuration during the eraly stages of booting linux, but I conclude
that when making a uImage one have to modify u-boot and the kernel if one
want to relocate the usage of dpram1 by the cpm uart driver. This might
have been obvious to most of you, but I was lost on this issue.
A mystery is why Dan Malek said it was a "very bad idea" to relocate the
smc buffer descriptors to anohter part of dpram1.
Maybe I will understand that one day too.
Thanks again for your help Mark.
-- Morten
"Mark Chambers" <markc@mail.com>
17.11.2004 17:37
To: <morten.banzon@axxessit.no>
cc:
Subject: Re: MPC82xx -- DPRAM1
Well, but the arch/ppc/boot stuff and u-boot are mutually exclusive,
right?
The arch/ppc/boot takes the kernel binary and wraps it in a very simple
bootloader. So it depends on your make options whether that code gets
compiled or not. So I think you've solved the mystery, that indeed the
bootloader sets up the SMCs to use that dpram memory. I guess the
philosophical question is, should it be left that way or not.
Mark Chambers
>
> >> No I still do not get this.
> >>
> >> The constant PROFF_SMC1_BASE is as far as I can see never used, only
> >> defined. Hence, the cpm or the smc will never be told by the kernel
> >> that
> >> there are pointers to the buffer descriptor tables located at
> >> PROFF_SMC1
> >> (offset zero) and PROFF_SMC2 (offset 64). Either I am blind or the
> >> kernel
> >> performs magic if this happens.
>
> >Look in arch/ppc/boot/simple/m8260_tty.c
>
> >This code, from what I can tell, is called early in boot to set up the
> >boot console. I haven't read the file very carefully, but I suspect,
> >from what Dan Malek said, that this file sets up the CPM to point the
> >SMCs at that area of dpram.
>
> Thanks for your reply.
>
> I have seen the code you are refering to. After compiling the kernel
> the arch/ppc/boot/simple directory contain no object files at all.
> Hence, I assumed that none of these files were compiled.
> To be asolutely sure I have removed the whole directory, and things
> work just fine. Which I take as a proof that nothing in the simple
> directory is involved in the configuration of smc1 as a console uart.
>
> I believe that there are only two file involved in configuring the
> cpm uart on a mpc82xx platform, namely:
> drivers/serial/cpm_uart/cpm_uart_cpm2.c
> drivers/serial/cpm_uart/cpm_uart_core.c
>
> None of these files modify the offset addresses 0x87FC (smc1) and
> 0x88FC(smc2) in the dpram2. Well, at least as far as I can tell.
> Hence, I believe the only reason why the cpm_uart driver in the kernel
> works, is because the u-boot bootloader does such a fine job.
>
> This might be intentional, I do not know but are seeking
> enlightenment.
>
> -- Morten
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: All-ones problem with FCC1 on MPC8541
From: Stefan Nickl @ 2004-11-18 10:13 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1098984003.11434.12.camel@lucy.pep-kaufbeuren.de>
On Thu, 2004-10-28 at 19:20 +0200, Stefan Nickl wrote:
> The packet sizes I receive look reasonable, but the buffers are
> filled only with 0xff. The same goes for sending, the contents
> of the buffers are OK (dhcp discover...), but when capturing
> the output on the other side with ethereal, the packet is again
> all 0xff.
To whom it may concern: We finally solved it!
>From what I can tell, it's a bug in both linuxppc-2.4 AND the manual.
It's all about the values of RIPTR and TIPTR in the FCC parameter RAM,
to work on the MPC8541/MPC8555 they must not assume the values that the
current public kernel sets them to, and what is suggested by the manual.
First the manual bug: "For best performance, it should be located in the
following address ranges: 0x3000-0x4000 or 0xB000-0xC000."
However, the "Internal Dual-Port Data RAM Memory Map" shows both of
these ranges as "Reserved" in the MPC8555 manual (different from the
MPC8560 manual). This is also not mentioned in the latest errata.
Next the linux bug: This is from cpm.h in the public kernel:
#ifdef CONFIG_8272
#define CPM_DATAONLY_SIZE ((uint)(8 * 1024) - CPM_DATAONLY_BASE)
#define CPM_FCC_SPECIAL_BASE ((uint)0x00009000)
#else
#define CPM_DATAONLY_SIZE ((uint)(16 * 1024) - CPM_DATAONLY_BASE)
#define CPM_FCC_SPECIAL_BASE ((uint)0x0000b000)
#endif
and this is from cpm.h in the metrowerks 8555 kernel:
#if (defined(CONFIG_8272) || defined(CONFIG_8555))
#define CPM_DATAONLY_SIZE ((uint)(8 * 1024) - CPM_DATAONLY_BASE)
#define CPM_FCC_SPECIAL_BASE ((uint)0x00009000)
#else
#define CPM_DATAONLY_SIZE ((uint)(16 * 1024) - CPM_DATAONLY_BASE)
#define CPM_FCC_SPECIAL_BASE ((uint)0x0000b000)
#endif
Note that little difference? :)
When the internal buffers are placed in the non-reserved region,
it just works.
Greetings,
--
Stefan Nickl
Kontron Modular Computers
^ permalink raw reply
* RE: Linuxppc-embedded Digest, Vol 3, Issue 25
From: Bastos Fernandez Alexandre @ 2004-11-18 8:32 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
Cc: 'Gerald.VanBaren@smiths-aerospace.com'
Gerald,
The MPC8272ADS board has also a 32 bits wide flash.
But in the doc, the BPS field appears in the first byte of the HRCW, bits
4-5,
which is 11 in "0x0E". So I should be using 32 bit wide access, not 16 bit
wide.
I am booting from flash, at least it should. Both jumper JP9 and SW2 are
selected following doc indications. In fact, those 16 bits I get, are from
flash's
contents. The jumper I was asking for would be another bad documented one.
I think you are right and my flash width is misconfigured. But it's the
reason
I cannot figure out. That is why I was asking for phantom jumpers.
Alex
> -----Original Message-----
>
> It looks like you have your HRCW/flash/BR0 (any or all of the
> preceeding) memory width misconfigured. That is why you are seeing
> 0000xyxy -- you should see xyxyxyxy (four repeated bytes). The PQ2FADS
> flash is 32 bits wide, is the MPC8272ADS? Your second HRCW byte "74" is
> selecting 8 bits port size (BPS field) -- it looks like you are
> configured for booting from EEPROM (8 bits wide), not flash. I suspect
> it should be "B4" which is what I'm using on the PQ2FADS.
>
> The PQ2FADS can select either flash (8MByte, 32 bits wide) or EEPROM
> (32K, 8 bits wide). Obviously, you want to select flash, not EEPROM.
> U-boot is not going to fit in EEPROM (per its design :-). Is that the
> "other jumper" you refer to?
>
> gvb
^ permalink raw reply
* Re: Best kernel for MPC8540 support?
From: Kumar Gala @ 2004-11-17 23:41 UTC (permalink / raw)
To: Keith J Outwater; +Cc: linuxppc-embedded
In-Reply-To: <OF58CA8327.E29A3083-ON07256F4F.007B13AE-07256F4F.007B6FBC@mck.us.ray.com>
For 2.4.x the linuxppc-2.4 tree on ppc.bkbits.net has support for
MPC8540. I'm not sure exactly what else you are asking about.
- kumar
On Nov 17, 2004, at 4:28 PM, Keith J Outwater wrote:
> Hello all -
> I am starting a kernel port to a custom design based on the MPC8540.
> Does anyone have a suggestion (and a download link) as to the best
> 2.4.x
> series kernel on which to base the port?
>
>
>
> Thanks,
> Keith Outwater
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Best kernel for MPC8540 support?
From: Keith J Outwater @ 2004-11-17 22:28 UTC (permalink / raw)
To: linuxppc-embedded
Hello all -
I am starting a kernel port to a custom design based on the MPC8540.
Does anyone have a suggestion (and a download link) as to the best 2.4.x
series kernel on which to base the port?
Thanks,
Keith Outwater
^ permalink raw reply
* 2.6.x IPsec
From: Mar James-MGIA2172 @ 2004-11-17 22:37 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
On Mon, Oct 18, 2004 at 09:41:17PM -0400, Mar James-MGIA2172 wrote:
>> Has anyone gotten IPsec to work on 2.6.x ppc?
>> In particular, success in compiling ipsec-tools.
>>
>> Jim
> I haven't - but I'll have to.
>
> What problems you encountered?
I was having problems cross-compiling the ipsec tools.
But then I just used the binaries from debian.org, and
IPsec worked flawlessly for 2.6.9.
Jim
^ permalink raw reply
* Re: 2.6.x IPsec
From: Marcelo Tosatti @ 2004-11-17 17:38 UTC (permalink / raw)
To: Mar James-MGIA2172; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <852DAFF1FD3BD611B68000D0B76FE77409F47A1C@pa06exm01.e1.bcs.mot.com>
On Mon, Oct 18, 2004 at 09:41:17PM -0400, Mar James-MGIA2172 wrote:
> Has anyone gotten IPsec to work on 2.6.x ppc?
> In particular, success in compiling ipsec-tools.
>
> Jim
I haven't - but I'll have to.
What problems you encountered?
^ permalink raw reply
* MPC8272ADS PCI device mapping
From: Milligan, Keath @ 2004-11-17 21:13 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
Hello,
I am having trouble getting PCI devices mapped correctly under Linux 2.4.22
running on an MPC8272ADS evaluation board.
I have multiple PCI-attached devices with a total of 512MB of prefetchable
memory and about 200MB of non-prefetchable memory address spaces in various
block sizes. All of the devices are behind a PCI-to-PCI bridge that is
plugged into the ADS.
At this stage in my project, these devices are initializing themselves to
base addresses that need to be moved when Linux boots on the 8272. The
problem I am having is that Linux is trying to remap everything, but is
unable to allocate regions for everything, so I end up with most of the
devices mapped to the same (invalid) address.
I've tried hacking the kernel PCI initialization to manually set all the
base addresses, but it seems to be ignoring that for the most part.
Could someone point me in the right direction to getting everything
initialized and mapped correctly?
Thanks
[-- Attachment #2: Type: text/html, Size: 5020 bytes --]
^ permalink raw reply
* Re: ELDK 3.1?
From: Wolfgang Denk @ 2004-11-17 20:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: Gala Kumar K.-galak, Embedded PPC Linux list
In-Reply-To: <C509F54D-38D2-11D9-9D5A-000393DBC2E8@freescale.com>
In message <C509F54D-38D2-11D9-9D5A-000393DBC2E8@freescale.com> you wrote:
>
> I thought from some posts on the u-boot lists that 3.1 was going to
> have a 85xx build as well?
Argh, you're persevering... ok, here we go.
Yes, ELDK 3.1 uses GCC-3.3.3 and binutils 2.14 to support 85xx etc.
There is a lot of new packets:
appWeb 1.2.2-1_5
bzip2 1.0.2-5_1
bzip2-devel 1.0.2-5_1
bzip2-libs 1.0.2-5_1
dhclient 3.0.1rc13-2
dhcp 3.0.1rc13-2
dosfstools 2.8-3
dropbear 0.43-1_2
file 3.39-9_2
lrzsz 0.12.20-14_1
net-snmp 5.0.6-17_2
net-snmp-devel 5.0.6-17_2
net-snmp-utils 5.0.6-17_2
As you can see, the focus is on network enabled devices: the powerful
"appWeb" web server, the "dropbear" SSH server, SNMP support, etc.
But there is also another group of new target packets:
autoconf 2.57-3_1
byacc 1.9-22_1
flex 2.5.4a-26_1
libtool 1.4.3-5_1
libtool-libs 1.4.3-5_1
m4 1.4.1-11_1
patch 2.5.4-14_1
rpm 4.1.1-1.8xa_7
rpm-build 4.1.1-1.8xa_7
rpm-devel 4.1.1-1.8xa_7
This is all that was missing for a more or less complete native build
environment; with the current ELDK you can easily build all those
software packets that are difficult to handle in a cross envrionment
(like Perl, to name just one). If you have the resources (RAM,
external storage) on your target you can even bootstrap a complete
Linux distribution on a target system.
ELDK 3.1 comes with support for PowerPC, ARM (new: XScale explicitely
supported), and MIPS (new: little-endian systems supported).
And there is some bug fixes and other minor extensions.
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
"Everything should be made as simple as possible, but not simpler."
- Albert Einstein
^ permalink raw reply
* Re: ELDK 3.1?
From: Kumar Gala @ 2004-11-17 19:56 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Gala Kumar K.-galak, Embedded PPC Linux list
In-Reply-To: <20041117172655.35BAAC1430@atlas.denx.de>
Nice answer ;)
I thought from some posts on the u-boot lists that 3.1 was going to=20
have a 85xx build as well?
- kumar
On Nov 17, 2004, at 11:26 AM, Wolfgang Denk wrote:
> In message <EF06BCF0-38BC-11D9-9D5A-000393DBC2E8@freescale.com> you=20
> wrote:
> > Out of interest, whats new in 3.1 version 3.0?
>
> Just some new software :-)
>
> > > It's actually out. I just wait with the announcement until all
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >=A0 mirrors picked it up. I have little influence on when they run=20=
> rsync,
> =A0=A0=A0=A0 ^^^^^^^^^^^^^^^^^^^^^
>
> Best regards,
>
> Wolfgang Denk
>
> --=20
> Software Engineering:=A0 Embedded and Realtime Systems,=A0 Embedded =
Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> Mr. Cole's Axiom:
> =A0=A0=A0=A0=A0=A0=A0 The sum of the intelligence on the planet is a =
constant;
> =A0=A0=A0=A0=A0=A0=A0 the population is growing.
^ 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