headers
Stephen Horton | 1 Aug 2008 03:38
Favicon

RE: mpc744x, Marvell mv6446x kernel guidance please

Hi Dale,

Thanks for the info; it was very informative. To follow-up on my
previous email:

1. I now have a working interrupt-map section in my .dts. PCI bus
initialization works with no visible errors.

2. I've deciphered the magic numbers in the cpu->pci window
configuration. The required information for disabling and re-enabling
BARS is located in the Marvell User's manual, Rev C, page 365, Table
141.

3. I'm a little smarter on the Ethernet configuration. I understand now
that Linux should actually just know about eth0 the RGMII connection
from Marvell to the Broadcom switch. Its upto me to configure the
additional Broadcom ports with whatever configuration (to meet my PICMG
2.16 requirements). I have all the Ethernet stuff initializing properly
(including eth0) with no errors; unfortunately, when I configure for
bootp and nfs boot over the network, there are no bootp requests coming
out of my board (verified with a sniffer, but link is up according to
Broadcom status bits and remote switch). So, I still have something
wrong here in my kernel code...

Thanks, again,
Stephen

-----Original Message-----
From: Dale Farnsworth [mailto:dale <at> farnsworth.org] 
Sent: Wednesday, July 30, 2008 6:11 PM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grant Likely | 1 Aug 2008 04:34
Picon

Re: Board is not booting - Please Help me

On Wed, Jul 30, 2008 at 01:14:52PM +0530, Naresh Bhat wrote:
> Hi Guys
> I have ML507 board.  By using "ml507_bsb_design_ppc440.zip"
> I have created the "Base System Builder" project and also
> 
> I am able to create the following files sucessfully.
> 
> 1. My own "DTS" file (attached with the mail)
> 2. My own "download.bit" file
> 3. My own ACE file. (Used the Montavista Pro 5.0 kernel., Kernel is compiled
> with ARCH=powerpc, CROSS_COMPILE=ppc_440-, used the ml507_defconfig)

Unfortunately, I'm not able to help much with the Montavista kernel
since I don't know anything about which version it is based on.  Have
you tried using the current mainline kernel source or Xilinx's published
git repo?

To use mainline, try copying your .dts file to
arch/powerpc/boot/dts/virtex440-myml507.dts and then build the kernel
with 'make simpleImage.virtex440-myml507'

g.
Permalink | Reply | 1 comment |
headers
- Reyneke | 1 Aug 2008 10:28
Picon
Favicon

Re: Lost time?


> Check the kernel's idea of what the timebase frequency is on both kernels.

> check for changes in the U-Boot and your u-Boot environment variables, device tree bolb content, etc, not
just the kernel

Thanks for all the feedback. This going to hurt, but the problem was embarrassingly simple. Our
CONFIG_SYS_CLK_FREQ in u-boot was wrongly defined (we did a u-boot upgrade as well - 1.3.3). Instead of
33000000 (doubled 16.5Mhz input clock) it was defined as 33333333. And there is your 0.6sec for every 60sec...

Using 20/20 hind site this is the first thing I SHOULD have checked, but there you go.

 Regards
   Jan Reyneke

_________________________________________________________________
The John Lewis Clearance - save up to 50% with FREE delivery
http://clk.atdmt.com/UKM/go/101719806/direct/01/
Permalink | Reply | 0 comments |
headers
Misbah khan | 1 Aug 2008 12:57

floating point support in the driver.


Hi all,

I have a DSP algorithm which i am running in the application even after
enabling the VFP support it is taking a lot of time to get executed hence 

I want to transform the same into the driver insted of an user application.
Can anybody suggest whether doing the same could be a better solution and
what could be the chalenges that i have to face by implimenting such
floating point support in the driver.

Is there a way in the application itself to make it execute faster.

---- Misbah <>< 
--

-- 
View this message in context: http://www.nabble.com/floating-point-support-in-the-driver.-tp18772109p18772109.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
Permalink | Reply | 8 comments |
headers
Laurent Pinchart | 1 Aug 2008 13:32

Re: floating point support in the driver.

On Friday 01 August 2008, Misbah khan wrote:
> 
> Hi all,
> 
> I have a DSP algorithm which i am running in the application even after
> enabling the VFP support it is taking a lot of time to get executed hence 
> 
> I want to transform the same into the driver insted of an user application.
> Can anybody suggest whether doing the same could be a better solution and
> what could be the chalenges that i have to face by implimenting such
> floating point support in the driver.
> 
> Is there a way in the application itself to make it execute faster.

Floating-point in the kernel should be avoided. FPU state save/restore operations are costly and are not
performed by the kernel when switching from userspace to kernelspace context. You will have to protect
floating-point sections with kernel_fpu_begin/kernel_fpu_end which, if I'm not mistaken, disables
preemption. That's probably not something you want to do. Why would the same code run faster in
kernelspace then userspace ?

--

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75
(Continue reading)

Permalink | Reply | 7 comments |
headers
Misbah khan | 1 Aug 2008 14:00

Re: floating point support in the driver.


I am not very clear Why floating point support in the Kernel should be
avoided ?

We want our DSP algorithm to run at the boot time and since kernel thread
having higher priority , i assume that it would be faster than user
application.

If i really have to speed up my application execution what mechanism will
you suggest me to try ?

After using Hardware VFP support also i am still laging the timing
requirement by 800 ms in my case 

---- Misbah <><

Laurent Pinchart-4 wrote:
> 
> On Friday 01 August 2008, Misbah khan wrote:
>> 
>> Hi all,
>> 
>> I have a DSP algorithm which i am running in the application even after
>> enabling the VFP support it is taking a lot of time to get executed hence 
>> 
>> I want to transform the same into the driver insted of an user
>> application.
>> Can anybody suggest whether doing the same could be a better solution and
>> what could be the chalenges that i have to face by implimenting such
>> floating point support in the driver.
(Continue reading)

Permalink | Reply | 6 comments |
headers
John Linn | 1 Aug 2008 17:00
Favicon

RE: Board is not booting - Please Help me

Hi Grant,

John Bonesio is working with Montavista to get these problems solved.

Thanks,
John

> -----Original Message-----
> From: linuxppc-embedded-bounces+john.linn=xilinx.com <at> ozlabs.org
[mailto:linuxppc-embedded-
> bounces+john.linn=xilinx.com <at> ozlabs.org] On Behalf Of Grant Likely
> Sent: Thursday, July 31, 2008 8:34 PM
> To: Naresh Bhat
> Cc: linuxppc-embedded <at> ozlabs.org
> Subject: Re: Board is not booting - Please Help me
> 
> On Wed, Jul 30, 2008 at 01:14:52PM +0530, Naresh Bhat wrote:
> > Hi Guys
> > I have ML507 board.  By using "ml507_bsb_design_ppc440.zip"
> > I have created the "Base System Builder" project and also
> >
> > I am able to create the following files sucessfully.
> >
> > 1. My own "DTS" file (attached with the mail)
> > 2. My own "download.bit" file
> > 3. My own ACE file. (Used the Montavista Pro 5.0 kernel., Kernel is
compiled
> > with ARCH=powerpc, CROSS_COMPILE=ppc_440-, used the ml507_defconfig)
> 
> Unfortunately, I'm not able to help much with the Montavista kernel
(Continue reading)

Permalink | Reply | 0 comments |
headers
M. Warner Losh | 1 Aug 2008 17:54

Re: floating point support in the driver.

In message: <18772952.post <at> talk.nabble.com>
            Misbah khan <misbah_khan <at> engineer.com> writes:
: I am not very clear Why floating point support in the Kernel should be
: avoided ?

Because saving the FPU state is expensive.  The kernel multiplexes the
FPU hardware among all the userland processes that use it.  For parts
of the kernel to effectively use the FPU, it would have to save the
state on traps into the kernel, and restore the state when returning
to userland.  This is a big drag on performance of the system.  There
are ways around this optimization where you save the fpu state
explicitly, but the expense si still there.

: We want our DSP algorithm to run at the boot time and since kernel thread
: having higher priority , i assume that it would be faster than user
: application.

Bad assumption.  User threads can get boots in priority in certain
cases.

If it really is just at boot time, before any other threads are
started, you likely can get away with it.

: If i really have to speed up my application execution what mechanism will
: you suggest me to try ?
: 
: After using Hardware VFP support also i am still laging the timing
: requirement by 800 ms in my case 

This sounds like a classic case of putting 20 pounds in a 10 pound bag
(Continue reading)

Permalink | Reply | 5 comments |
headers
Paul Smith | 2 Aug 2008 04:40
Picon
Favicon

Creating a wrapped zImage.initrd -- can't start the trampoline?

Hi all;

I'm working with a PPC 460EX-based board.  I have a 2.6.25.10-based
kernel I obtained from the DENX git tree which contains a port to this
board, under arch/powerpc.

I can build a kernel and have it downloaded and booting using u-boot,
providing the blob and appropriate kernel parameters, after having done
a standard "make zImage" with the appropriate configs etc.  All good so
far.

However, my ultimate target board uses a custom bootloader, not uboot,
which is very, very simple (please don't suggest we just switch to
uboot--that argument has been already had, and lost :-/)  I had a
previous version of Linux, 2.6.14, booting on a predecessor of this
board based on the 440GX with the same bootloader, but the creation of
that image was done under arch/ppc and it was pretty different (I'm
discovering).  And, I didn't do that port anyway.

Anyway, I need to generate an all-in-one image containing the kernel and
the initrd, and the trampoline code tacked onto it to turn it into an
ELF image.  I'm worried I'll need to write a custom platform_init() but
for now I'm just using of.c.

>From what I can tell, the wrapper script seems to be intended to have
the ability to generate an image like this.  I've tried just running
"make zImage.initrd" after putting the ramdisk.initrd.gz in the right
place, and it seems to create an image OK: using file shows it to be
"ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV),
statically linked, not stripped", which seems correct.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Josh Boyer | 2 Aug 2008 14:35
Picon

Re: Creating a wrapped zImage.initrd -- can't start the trampoline?

On Fri, 2008-08-01 at 22:40 -0400, Paul Smith wrote:
> Hi all;
>         
> I'm working with a PPC 460EX-based board.  I have a 2.6.25.10-based
> kernel I obtained from the DENX git tree which contains a port to this
> board, under arch/powerpc.
> 
> I can build a kernel and have it downloaded and booting using u-boot,
> providing the blob and appropriate kernel parameters, after having done
> a standard "make zImage" with the appropriate configs etc.  All good so
> far.
> 
> However, my ultimate target board uses a custom bootloader, not uboot,
> which is very, very simple (please don't suggest we just switch to
> uboot--that argument has been already had, and lost :-/)  I had a
> previous version of Linux, 2.6.14, booting on a predecessor of this
> board based on the 440GX with the same bootloader, but the creation of
> that image was done under arch/ppc and it was pretty different (I'm
> discovering).  And, I didn't do that port anyway.
> 
> Anyway, I need to generate an all-in-one image containing the kernel and
> the initrd, and the trampoline code tacked onto it to turn it into an
> ELF image.  I'm worried I'll need to write a custom platform_init() but
> for now I'm just using of.c.

It needs the vmlinux, dtb, and initrd in a single image.  The dtb is
required for arch/powerpc ports.

> >From what I can tell, the wrapper script seems to be intended to have
> the ability to generate an image like this.  I've tried just running
(Continue reading)

Permalink | Reply | 1 comment |

Gmane