* Re: UIO not working on ppc405 onchip registers
From: super.firetwister @ 2008-07-22 7:47 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linuxppc-dev@ozlabs.org, linux-embedded@vger.kernel.org
In-Reply-To: <20080722061730.GB12576@digi.com>
Hello Uwe,
On Tuesday 22 July 2008, Uwe Kleine-König wrote:
> I don't know powerpc in general nor ppc405ep in detail but IIRC arm has
> problems if some memory is mapped twice. Might this be the problem
> here?
Maybee, the emac0 (0xef600800) and emac1 (0xef600900) get mapped as well,
because AFAIK I have to map a whole pagesize (0x1000).
> > + int uiofd = open(UIO_DEV,O_RDWR);
>
> For debugging this is OK, in the final application you should add some
> tests. Check the UIO documentation for the details.
The whole example was meant to be short.
> > +static int uio_gpio_remove(struct device *dev)
> > +{
> > + uio_unregister_device(&info);
> > + info.mem[0].addr = 0;
> > + info.mem[0].size = 0;
> > + return 0;
> > +}
>
> Are you sure that overwriting info.mem[0].addr is a good idea? Then
> unbinding the platform device and rebinding it fails to do the right
> thing for sure.
This was stolen from uio_dummy. So this might become a common error :(
Thanks a lot for your comments, I will try to get an exclusive memory region
mapped.
Markus
^ permalink raw reply
* Re: UIO not working on ppc405 onchip registers
From: super.firetwister @ 2008-07-22 7:48 UTC (permalink / raw)
To: Ben Nizette; +Cc: linuxppc-dev@ozlabs.org, linux-embedded@vger.kernel.org
In-Reply-To: <1216708967.4004.238.camel@moss.renham>
On Tuesday 22 July 2008, Ben Nizette wrote:
> As an aside, you sure you want to do this anyway?
No ;)
> I'd suggest that you
> just do a gpio chip driver for this, tie it in to gpiolib and use the
> gpiolib user interface (which IIRC has only made it as far as -mm but is
> on the way up). This gives kernel internals nice access to the pins as
> well through the standard gpio framework.
This was just an example to make it others easier to reproduce my problem. My
goal is to have a soft spi driver in userspace, which would probably be
slower if it uses gpiolib. This driver is integrated in the application I
want to port to Linux.
Thanks
Markus
^ permalink raw reply
* Re: UIO not working on ppc405 onchip registers
From: Ben Nizette @ 2008-07-22 7:52 UTC (permalink / raw)
To: super.firetwister; +Cc: linuxppc-dev@ozlabs.org, linux-embedded@vger.kernel.org
In-Reply-To: <200807220948.51053.super.firetwister@gmail.com>
On Tue, 2008-07-22 at 09:48 +0200, super.firetwister@googlemail.com
wrote:
> On Tuesday 22 July 2008, Ben Nizette wrote:
>
> > As an aside, you sure you want to do this anyway?
>
> No ;)
>
>
> > I'd suggest that you
> > just do a gpio chip driver for this, tie it in to gpiolib and use the
> > gpiolib user interface (which IIRC has only made it as far as -mm but is
> > on the way up). This gives kernel internals nice access to the pins as
> > well through the standard gpio framework.
>
> This was just an example to make it others easier to reproduce my problem. My
> goal is to have a soft spi driver in userspace, which would probably be
> slower if it uses gpiolib. This driver is integrated in the application I
> want to port to Linux.
Ah right, cool. I donno what the speed would be like, but both David
Brownell and Michael Buesch both have spi-over-gpio patches floating
around (eg [1]). That, plus the spidev interface, might at least be
worth a try..?
But I'll let you get back to solving the UIO problem at hand :-D
--Ben.
[1] http://lwn.net/Articles/290066/
^ permalink raw reply
* Re: UIO not working on ppc405 onchip registers
From: super.firetwister @ 2008-07-22 16:20 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linuxppc-dev@ozlabs.org, linux-embedded@vger.kernel.org
In-Reply-To: <200807220947.43074.super.firetwister@gmail.com>
On Tuesday 22 July 2008, super.firetwister@gmail.com wrote:
> Hello Uwe,
>
> On Tuesday 22 July 2008, Uwe Kleine-König wrote:
> > I don't know powerpc in general nor ppc405ep in detail but IIRC arm has
> > problems if some memory is mapped twice. Might this be the problem
> > here?
>
> Maybee, the emac0 (0xef600800) and emac1 (0xef600900) get mapped as well,
> because AFAIK I have to map a whole pagesize (0x1000).
Same problem without emac module loaded.
Did anybody tried to reproduce the problem?
Regards
Markus
^ permalink raw reply
* Kernel not taking command line arguements from bootloader
From: sourya roy @ 2008-07-23 6:37 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <a2cf9bac0807222132y69a22c7bi5a46ca2fa5eba03b@mail.gmail.com>
Dear All,
I am trying to port linux to a Cogent CSB 637 board (AT91RM9200). The
kernel is loading up but is unable to mount the cramfs root filesystem
image from the flash memory.
I am using uMon as the bootloader and it seems that the it is not
passing the command line arguments to the kernel.
In the startlinux script (shell script to start the kernel, attached
with this email), the kernel command line is defined as:
heap -m 1024
# (note: -s creates a new string; -S appends to an existing string)
# (note: the trailing spaces are so that appends work as expected)
#
pm -s $MALLOC "mem=32M console=ttyS0,38400 "
pm -S $MALLOC "ip=$IPADD:$NFSSERVER:$GIPADD:$NETMASK::eth0:off "
#
# TODO: pick from and/or adapt one of the two following
# examples to specify the source of the root filesystem:
#
# this example uses MTD and flash for the root filesystem
pm -S $MALLOC "root=31:0 mtdparts=$TARGET:$ROOTDIR_SIZE@$ROOTDIR_BASE(root)ro "
#
# Example that tacks on video parameters
# (for the CSB625's 640x480 display, in this case)
# pm -S $MALLOC
"video=pxafb:mode:640x480-16,active,left:1,right:161,hsynclen:1,upper:0,lower:31,vsynclen:32,hsync:0,vsync:0,outputen:1,pixclockpol:0,pixclock:25000
"
#
# Launch the kernel, pass it the command line
call $APPRAMBASE 0 648 $MALLOC
exit
#
But the kernel gets booted with the default command line:
Kernel command line: mem=32M console=ttyS0,38400 initrd=0x20410000,3145728 rootw
I have also tried to pass the command line by typing it directly after
the call $APPRAMBASE, but of no avail.
call $APPRAMBASE 0 648 mem=32M console=ttyS0,38400
ip=$IPADD:$NFSSERVER:$GIPADD:$NETMASK::eth0:off root=31:0
mtdparts=$TARGET:$ROOTDIR_SIZE@$ROOTDIR_BASE(root)ro
Is it something wrong in the bootloader or some kernel configuration
problem? Is it something due to no/wrong ATAGs passed by the
bootloader?
(I am running a Kernel 2.6.26 image compiled using csb637_defconfig. I
have also tried the same with kernels 2.6.10, 2.6.20, 2.6.24 but I
still get the same error).
Thanks
Sourya
--
Sourya Roy
Electrical Engineering (Class of 2011)
Northwestern University
Evanston, Illinois
souryaroy@gmail.com
*****************************
The startlinux script for your reference:
###############################################################################
# GX-Linux Startup Script for both ROMFS and NFS Server Filesystem mounts
###############################################################################
# (c)2005 Microcross, Inc.
# Last update: 20050607
###############################################################################
#
#
# Files/Target defined in TFS (Tiny FileSystem)
set TARGET flash00
set ROOTDIR romdisk
set KERNEL zImage
#
# DHCPWAIT:
echo sleep 1...
sleep 1
if $ARG1 seq "nfs" goto BOOTNFS
if $IPADD seq DHCP goto DHCPWAIT
if $IPADD seq DHCPV goto DHCPWAIT
if $IPADD seq DHCPv goto DHCPWAIT
echo IP Address OK, $IPADD
#
# TODO: set this variable
# Set if you are going to use a TFTP server
set TFTPSERVER 192.168.0.220
###############################################################################
#
#
#
# check for filesystem image in flash
tfs base $ROOTDIR ROOTDIR_BASE
tfs size $ROOTDIR ROOTDIR_SIZE
#
# Verify that a seemingly-useful filesystemthe
# image is present; abort if it isn't
# (delete these two tests if you are using NFS exclusively)
if $ROOTDIR_BASE seq \$ROOTDIR_BASE goto NO_FILE
if $ROOTDIR_SIZE seq \$ROOTDIR_SIZE goto NO_FILE
#
# ok, we found what looks like a filesystem in flash,
# (based only on the name of the file)
# do some math to figure out where it is
set ROOTDIR_BASE=$ROOTDIR_BASE-$BOOTROMBASE
echo $ROOTDIR: size=$ROOTDIR_SIZE base=$ROOTDIR_BASE
#
# Check for a kernel
tfs base $KERNEL KERNEL_BASE
tfs size $KERNEL KERNEL_SIZE
#
if $KERNEL_BASE seq \$KERNEL_BASE goto GET_KERNEL
if $KERNEL_SIZE seq \$KERNEL_SIZE goto GET_KERNEL
#
# Found a kernel, load it into RAM
tfs cp $KERNEL $APPRAMBASE
echo $KERNEL: size=$KERNEL_SIZE base=$APPRAMBASE
#
# GOT_KERNEL:
#
# allocate memory for the kernel command line
# (as a side effect, this command sets $MALLOC)
heap -m 1024
#
###############################################################################
#
if $ARG1 seq "nfs" goto BOOTNFS
#
###############################################################################
#
# (note: -s creates a new string; -S appends to an existing string)
# (note: the trailing spaces are so that appends work as expected)
#
pm -s $MALLOC "mem=32M console=ttyS0,38400 "
pm -S $MALLOC "ip=$IPADD:$NFSSERVER:$GIPADD:$NETMASK::eth0:off "
#
# TODO: pick from and/or adapt one of the two following
# examples to specify the source of the root filesystem:
#
# this example uses MTD and flash for the root filesystem
pm -S $MALLOC "root=31:0 mtdparts=$TARGET:$ROOTDIR_SIZE@$ROOTDIR_BASE(root)ro "
#
# Example that tacks on video parameters
# (for the CSB625's 640x480 display, in this case)
# pm -S $MALLOC
"video=pxafb:mode:640x480-16,active,left:1,right:161,hsynclen:1,upper:0,lower:31,vsynclen:32,hsync:0,vsync:0,outputen:1,pixclockpol:0,pixclock:25000
"
#
# Launch the kernel, pass it the command line
call $APPRAMBASE 0 648 $MALLOC
exit
#
###############################################################################
#
# BOOTNFS:
#
###############################################################################
#
#
if $ARG2 sne \$ARG2 gosub SET_NFSSERVER
if $NFSSERVER seq \$NFSSERVER goto NO_NFSSERVER
#
if $ARG3 sne \$ARG3 gosub SET_NFSPATH
if $NFSPATH seq \$NFSPATH goto NO_NFSPATH
goto NFS_BOOT
#
# SET_NFSSERVER:
set NFSSERVER $ARG2
return
#
# SET_NFSPATH:
set NFSPATH $ARG3
return
#
#
# NFS_BOOT:
#
# (note: -s creates a new string; -S appends to an existing string)
# (note: the trailing spaces are so that appends work as expected)
#
pm -s $MALLOC "mem=32M console=ttyS0,38400 "
pm -S $MALLOC "ip=$IPADD:$NFSSERVER:$GIPADD:$NETMASK::eth0:off "
#
#
# This example uses an NFS server for the root filesystem
pm -S $MALLOC "root=0:0 nfsroot=$NFSSERVER:$NFSPATH rw "
#
# Example that tacks on video parameters
# (for the CSB625's 640x480 display, in this case)
# pm -S $MALLOC
"video=pxafb:mode:640x480-16,active,left:1,right:161,hsynclen:1,upper:0,lower:4,vsynclen:32,hsync:0,vsync:0,outputen:1,pixclockpol:0,pixclock:25000
"
#
# Launch the kernel, pass it the combined command line
call $APPRAMBASE $MALLOC
exit
#
###############################################################################
#
#
# GET_KERNEL:
# download kernel from TFTP server
tftp $TFTPSERVER get $BOARD/$KERNEL
if $TFTPGET seq \$TFTPGET goto NO_KERNEL
#
echo $KERNEL: size=$TFTPGET base=$APPRAMBASE
goto GOT_KERNEL
#
###############################################################################
#
# Error Handling
#
###############################################################################
#
# NO_FILE:
echo Cannot find filesystem: $ROOTDIR
echo Abort.
exit
#
# NO_KERNEL:
echo Cannot find kernel file: $KERNEL
echo Abort.
exit
#
# NO_NFSSERVER:
echo Cannot find NFS server, check your \$NFSSERVER variable
echo "startlinux nfs <NFS-IP-ADDR> <NFS-PATH>"
echo Example startlinux nfs 192.168.0.2 /usr/src/gxlinux/rootfs
exit
#
# NO_NFSPATH:
echo Cannot find NFS server path, check your \$NFSPATH variable
echo "startlinux nfs <NFS-IP-ADDR> <NFS-PATH>"
echo Example startlinux nfs 192.168.0.2 /usr/src/gxlinux/rootfs
exit
^ permalink raw reply
* Useful IRC channels
From: Shaz @ 2008-07-23 10:41 UTC (permalink / raw)
To: linux-embedded; +Cc: Security Engineering Archive
Hi,
Can anyone indicate some useful and active IRC channels on embedded
Linux and cross compilations? I need to sort out some tit bits, which
are not feasible and relevant for this list in some way :)
Thanx.
--
Shaz
^ permalink raw reply
* Re: Useful IRC channels
From: Robert Schwebel @ 2008-07-23 11:07 UTC (permalink / raw)
To: Shaz; +Cc: linux-embedded, Security Engineering Archive
In-Reply-To: <7b740b700807230341x2cdb082dv58393187d64b0671@mail.gmail.com>
On Wed, Jul 23, 2008 at 03:41:23PM +0500, Shaz wrote:
> Can anyone indicate some useful and active IRC channels on embedded
> Linux and cross compilations? I need to sort out some tit bits, which
> are not feasible and relevant for this list in some way :)
#ptxdist on freenode.net
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: Useful IRC channels
From: Wookey @ 2008-07-23 14:23 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <7b740b700807230341x2cdb082dv58393187d64b0671@mail.gmail.com>
On 2008-07-23 15:41 +0500, Shaz wrote:
> Hi,
>
> Can anyone indicate some useful and active IRC channels on embedded
> Linux and cross compilations? I need to sort out some tit bits, which
> are not feasible and relevant for this list in some way :)
#oe on freenode
#emdebian on oftc
I'm not aware of any non-distro-specific channels
Wookey
--
Principal hats: Balloonz - Toby Churchill - Aleph One - Debian
http://wookware.org/
^ permalink raw reply
* Re: Useful IRC channels
From: Samuel Robb @ 2008-07-23 14:59 UTC (permalink / raw)
To: Robert Schwebel; +Cc: Shaz, linux-embedded, Security Engineering Archive
In-Reply-To: <20080723110755.GI4319@pengutronix.de>
On Wed, 2008-07-23 at 13:07 +0200, Robert Schwebel wrote:
> On Wed, Jul 23, 2008 at 03:41:23PM +0500, Shaz wrote:
> > Can anyone indicate some useful and active IRC channels on embedded
> > Linux and cross compilations? I need to sort out some tit bits, which
> > are not feasible and relevant for this list in some way :)
>
> #ptxdist on freenode.net
>
> rsc
Also #edev on freenode.net
-Samrobb
^ permalink raw reply
* Re: optimal hardware design for an ARM9 based single board computer to work with existing linux drivers
From: Jean-Christophe PLAGNIOL-VILLARD @ 2008-07-23 20:19 UTC (permalink / raw)
To: Stefan Schoenleitner; +Cc: Robert Schwebel, linux-embedded
In-Reply-To: <486F6DA7.2050505@gmail.com>
On 14:48 Sat 05 Jul , Stefan Schoenleitner wrote:
>
>
> Robert Schwebel wrote:
> >
> > If you want to have something which has good community support, check
> > what the mainline Linux kernel supports and base your stuff on that.
>
>
> What do you think of this board ?
> http://www.olimex.com/dev/sam9-L9260.html
If you are looking for a mainline Linux kernel and U-Boot, you could
take a look on the AT91SAM9260 or AT91SAM9263
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH] (updated, rolled up) make section names compatible with -ffunction-sections -fdata-sections
From: Jesper Nilsson @ 2008-07-23 20:21 UTC (permalink / raw)
To: Denys Vlasenko
Cc: Andrew Morton, mingo@elte.hu, x86@kernel.org, James Bottomley,
Russell King, David Howells, Ralf Baechle, Lennert Buytenhek,
Josh Boyer, Paul Mackerras, David Woodhouse, Andi Kleen,
torvalds@linux-foundation.org, Paul Gortmaker,
linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org,
Tim Bird, Martin Schwidefsky, Dave Miller
In-Reply-To: <200807172213.37411.vda.linux@googlemail.com>
On Thu, Jul 17, 2008 at 10:13:37PM +0200, Denys Vlasenko wrote:
> Hi Andrew,
>
> Here is the update against current Linus tree,
> rolled up into one patch.
>
> James Bottomley suggested a different naming scheme:
> instead of swapping parts (.text.head -> .head.text),
> prepend .kernel to our special section names.
> This patch implements his idea.
>
> ppc and v850 are dropped per comments from arch people.
> parisc and x86 had minor fixes. x86 fix added proper
> executable bits to a section:
>
> -.section ".text.head"
> +.section ".kernel.text.head","ax",@progbits
>
> Does arch/m68k/kernel/sun3-head.S need the same fix?
>
> The patch is run-tested on x86_64.
>
> I would like to ask arch maintainers to ACK/NAK this patch,
> and Andrew to act accordingly.
>
> Changelog follows:
>
>
>
> The purpose of these patches is to make kernel buildable
> with "gcc -ffunction-sections -fdata-sections".
>
> The problem is that with -ffunction-sections -fdata-sections gcc
> creates sections like .text.head and .data.nosave
> whenever someone has innocuous code like this:
>
> static void head(...) {...}
>
> or this:
>
> int f(...) { static int nosave; ... }
>
> somewhere in the kernel.
>
> Kernel linker script is confused by such names and puts these sections
> in wrong places.
>
> This patch renames all "magic" section names used by kernel
> to not have this format, eliminating the possibility of such collisions.
>
> Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
CRIS part:
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
> vda
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* Re: Useful IRC channels
From: Bill Traynor @ 2008-07-23 21:02 UTC (permalink / raw)
To: Shaz; +Cc: linux-embedded, Security Engineering Archive
In-Reply-To: <7b740b700807230341x2cdb082dv58393187d64b0671@mail.gmail.com>
> Hi,
>
> Can anyone indicate some useful and active IRC channels on embedded
> Linux and cross compilations? I need to sort out some tit bits, which
> are not feasible and relevant for this list in some way :)
#elinux on freenode.
Most of it's inhabitants are in #edev as well.
>
> Thanx.
>
> --
> Shaz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Useful IRC channels
From: Shaz @ 2008-07-24 8:45 UTC (permalink / raw)
To: Bill Traynor; +Cc: linux-embedded, Security Engineering Archive
In-Reply-To: <72427c9767f47b923269ec246f93761d.squirrel@www.geekisp.com>
Thanks for the tips. Have fun.
On Thu, Jul 24, 2008 at 2:02 AM, Bill Traynor <wmat@naoi.ca> wrote:
>> Hi,
>>
>> Can anyone indicate some useful and active IRC channels on embedded
>> Linux and cross compilations? I need to sort out some tit bits, which
>> are not feasible and relevant for this list in some way :)
>
> #elinux on freenode.
>
> Most of it's inhabitants are in #edev as well.
>
>>
>> Thanx.
>>
>> --
>> Shaz
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-embedded"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
--
Shaz
^ permalink raw reply
* Porting tips
From: Shaz @ 2008-07-26 11:57 UTC (permalink / raw)
To: linux-embedded
Hi,
I am finding some issues and difficulties in porting some application
but could not find any useful help and tips from google. Can anyone
give me some pointers regarding porting applications with respect to
architectural differences in x86 to arm and build tools like adjusting
simple makefiles for cross compilation.
Apologies for off the topic request but thought that relevant pros
will be available on this list :) I will appreciate if relevant
mailing lists can be also pointed out.
thanx.
--
Shaz
^ permalink raw reply
* [ANN] Device Tree Mailing List
From: Hugh Blemings @ 2008-07-26 15:26 UTC (permalink / raw)
To: linux-embedded, linux-kernel
Hiya,
Grant Likely and Josh Boyer organised a BoF session on Device Trees on Thursday at OLS, all told about a dozen folk attended.
Grant has posted a summary of the BoF to the list which is available in the archives - http://ozlabs.org/pipermail/devicetree-discuss/2008-July/000004.html
Amongst other things, it was agreed that there was now enough non-PowerPC specific interest in Device Trees to make a generic list a useful thing to have, so have gone ahead and got one set up;
https://ozlabs.org/mailman/listinfo/devicetree-discuss
All interested parties welcome :)
Regards,
Hugh
^ permalink raw reply
* RE: Porting tips
From: Turquette, Mike @ 2008-07-26 15:59 UTC (permalink / raw)
To: Shaz, linux-embedded
In-Reply-To: <7b740b700807260457u44419d16s6179c9ab525e8fe8@mail.gmail.com>
Shaz,
> From: linux-embedded-owner@vger.kernel.org [mailto:linux-embedded-
> Hi,
>
> I am finding some issues and difficulties in porting some application
> but could not find any useful help and tips from google. Can anyone
> give me some pointers regarding porting applications with respect to
> architectural differences in x86 to arm and build tools like adjusting
> simple makefiles for cross compilation.
Well this list is mostly pointed at Linux issues and not general application development. Still you might find some off-list help if you stated what manner of issues you are running in to. Are you having trouble with autotools? Any packages in particular you can list that are giving you trouble?
> Apologies for off the topic request but thought that relevant pros
> will be available on this list :) I will appreciate if relevant
> mailing lists can be also pointed out.
Also, the irc channels listed in a recent mailing should be helpful. Try pinging some of the more active folks on irc.
> thanx.
>
> --
> Shaz
> --
Mike
^ permalink raw reply
* testing ethernet device with external loopback
From: Sebastien Fauris @ 2008-07-27 8:47 UTC (permalink / raw)
To: linux-embedded
Hi,
for hardware testing purposes, I would like to perform an external
loopback on my ethernet interface. For this, I wrote 2 little
executables, one sending a raw ethernet packet (using 'sendto') on a
socket opened with the parameters PF_PACKET, SOCK_RAW,
htons(ETH_P_ALL), the other one doing a recvfrom from a raw socket.
The problem is that on the reception side, I always receive what I send,
even when
the external RJ45 stub is not plugged !
Is there a way to tell to the kernel on the reception side that I want
to get only packets coming from the external world ?
Thanks,
Sebastien.
^ permalink raw reply
* Re: testing ethernet device with external loopback
From: James Chapman @ 2008-07-27 11:07 UTC (permalink / raw)
To: Sebastien Fauris; +Cc: linux-embedded
In-Reply-To: <488C3608.3000104@gmail.com>
Sebastien Fauris wrote:
> Hi,
>
> for hardware testing purposes, I would like to perform an external
> loopback on my ethernet interface. For this, I wrote 2 little
> executables, one sending a raw ethernet packet (using 'sendto') on a
> socket opened with the parameters PF_PACKET, SOCK_RAW,
> htons(ETH_P_ALL), the other one doing a recvfrom from a raw socket.
> The problem is that on the reception side, I always receive what I send,
> even when
> the external RJ45 stub is not plugged !
Presumably you are trying to sendto() a local IP address. When you do
this, packets are looped back before they get to the ethernet driver.
Pull out all eth cables and do a ping to one of your local IP addresses
and you'll see ping responses. :)
> Is there a way to tell to the kernel on the reception side that I want
> to get only packets coming from the external world ?
Try using pktgen to generate packets from the kernel to the IP address
of your interface. The packets are generated inside the kernel, below
the IP stack, so they don't get looped back in software. With pktgen,
you set MAC addresses, IP addresses, protocol etc using a /proc
interface. There is documentation in the kernel source tree, or google
pktgen.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: testing ethernet device with external loopback
From: David Anders @ 2008-07-27 16:25 UTC (permalink / raw)
To: linux-embedded, Sebastien Fauris
In-Reply-To: <488C3608.3000104@gmail.com>
Sebastien,
check out the snull network driver from the "Linux Device Drivers" book. it has a short explanation on how to "trick" the kernel into sending the packet even though the destination is on the local machine:
http://www.linuxdriver.co.il/ldd3/chp-17-sect-1.shtml
dave aka prpplague
--- On Sun, 7/27/08, Sebastien Fauris <titelive72@gmail.com> wrote:
> From: Sebastien Fauris <titelive72@gmail.com>
> Subject: testing ethernet device with external loopback
> To: linux-embedded@vger.kernel.org
> Date: Sunday, July 27, 2008, 3:47 AM
> Hi,
>
> for hardware testing purposes, I would like to perform an
> external
> loopback on my ethernet interface. For this, I wrote 2
> little
> executables, one sending a raw ethernet packet (using
> 'sendto') on a
> socket opened with the parameters PF_PACKET, SOCK_RAW,
> htons(ETH_P_ALL), the other one doing a recvfrom from a raw
> socket.
> The problem is that on the reception side, I always receive
> what I send,
> even when
> the external RJ45 stub is not plugged !
> Is there a way to tell to the kernel on the reception side
> that I want
> to get only packets coming from the external world ?
>
> Thanks,
>
> Sebastien.
>
> --
> To unsubscribe from this list: send the line
> "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* prevalence of C++ in embedded linux?
From: Robert P. J. Day @ 2008-07-28 15:43 UTC (permalink / raw)
To: Embedded Linux mailing list
just curious -- how many folks are working in C++ in their embedded
linux work?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Chris @ 2008-07-28 15:54 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Embedded Linux mailing list
In-Reply-To: <alpine.LFD.1.10.0807281142430.4286@localhost.localdomain>
In my experience, > 50%, especially the larger projects such as set top
boxes, printers, mobile devices...
Chris.
Robert P. J. Day wrote:
> just curious -- how many folks are working in C++ in their embedded
> linux work?
>
> rday
> --
>
> ========================================================================
> Robert P. J. Day
> Linux Consulting, Training and Annoying Kernel Pedantry:
> Have classroom, will lecture.
>
> http://crashcourse.ca Waterloo, Ontario, CANADA
> ========================================================================
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Jamie Lokier @ 2008-07-28 15:55 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Embedded Linux mailing list
In-Reply-To: <alpine.LFD.1.10.0807281142430.4286@localhost.localdomain>
Robert P. J. Day wrote:
> just curious -- how many folks are working in C++ in their embedded
> linux work?
I'm avoiding it, because of reports of occasional elf2flt relocation
errors when using C++ a few months ago, on this list.
However, some of the libraries I'm using have some C++ in them, and a
C API wrapped around the C++ core! I'm glad they use a C wrapper, as
they only supply binaries build with GCC 2.95.3, I have the impression
the C++ ABI has changed between that and GCC 4.x. But I haven't checked.
All systems using Qt (such as Qtopia) will use C++ a lot, so it is
well supported.
-- Jamie
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Domenico Andreoli @ 2008-07-28 16:15 UTC (permalink / raw)
To: Embedded Linux mailing list
In-Reply-To: <alpine.LFD.1.10.0807281142430.4286@localhost.localdomain>
On Mon, Jul 28, 2008 at 11:43:17AM -0400, Robert P. J. Day wrote:
>
> just curious -- how many folks are working in C++ in their embedded
> linux work?
my app is mostly written in c++/boost. fat stuff on my not-so-embedded
set-top-box, but if I had to rewrite it in plain C _I_ would get
very fat... :)
cheers,
Domenico
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Matthias Kaehlcke @ 2008-07-28 17:30 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Embedded Linux mailing list
In-Reply-To: <alpine.LFD.1.10.0807281142430.4286@localhost.localdomain>
El Mon, Jul 28, 2008 at 11:43:17AM -0400 Robert P. J. Day ha dit:
> just curious -- how many folks are working in C++ in their embedded
> linux work?
i'm working on an embedded project in c++. until now the experience is
positive (i have a large background with c++ in non-embedded project),
probably new projects will also be done in c++.
--
Matthias Kaehlcke
Embedded Linux Engineer
Barcelona
For to be free is not merely to cast off
one's chains, but to live in a way that
respects and enhances the freedom of others
(Nelson Mandela)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
^ permalink raw reply
* Re: prevalence of C++ in embedded linux?
From: Ben Nizette @ 2008-07-28 21:47 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Embedded Linux mailing list
In-Reply-To: <alpine.LFD.1.10.0807281142430.4286@localhost.localdomain>
On Mon, 2008-07-28 at 11:43 -0400, Robert P. J. Day wrote:
> just curious -- how many folks are working in C++ in their embedded
> linux work?
I hang out on AVRFreaks - an AVR and AVR32 support forum - quite a bit.
I personally think C++ is the language of the devil but I'd say that
around 50% of the people I talk to on 'freaks think otherwise. It's
certainly the language of choice.
There's also a surprising number (~5%?) using Java on a small JVM (eg
JamVM) and about the same using Python.
Of course a largish number don't really need to write any code at all.
They just need to wire up existing programs to do what they want then
maybe glue a bit of PHP between that and the user so it doesn't /look/
like Linux from the outside.
--Ben.
>
> rday
> --
^ 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