* Re: [PATCH] Add support for lite5200b board.
From: John Rigby @ 2006-01-30 18:52 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Linuxppc-embedded
In-Reply-To: <43DD3FFC.3040608@246tNt.com>
I tried:
git clone http://gitbits.246tnt.com/gitbits/linux-2.6-mpc52xx
and got:
defaulting to local storage area
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?
On 1/29/06, Sylvain Munaut <tnt@246tnt.com> wrote:
> John Rigby wrote:
> >
> >
> > On 1/25/06, *Sylvain Munaut* <tnt@246tnt.com <mailto:tnt@246tnt.com>> w=
rote:
> >
> >
> >
> > Should apply fine on vanilla. My suggestion for now is take vanilla=
,
> > apply this patch, then the 2-3 patch from Andrey for BestComm and s=
tuff.
> >
> >
> > I was working on getting bestcomm and fec working, but forward porting
> > my old 2.6.10 code to current is turning out to be more difficult than =
I
> > expected.
> > If you already have working code then I'll stop working on them.
> >
> > Where are these patches? I'm new to this list so I don't have much
> > history.
> > Would I find these patches in the archive?
>
> Checkout (with git)
>
> http://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx
>
> then apply
>
> http://gitbits.246tNt.com/patches/bcomm-to-split.diff
>
> (I haven't cleanly splitted it up yet and right now I must go, so it's
> probably gonna be in the git tree this week, under the 'bestcomm' head ;)
>
>
> Please report if it works fine on your board (both lite5200 and
> lite5200b reports are welcome). I only did quick tests.
>
>
>
> Sylvain
>
^ permalink raw reply
* Re: [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Ralf Baechle @ 2006-01-30 17:06 UTC (permalink / raw)
To: Stuart Brady
Cc: linux-mips, linux-m68k, linux-ia64, Ian Molton, Andi Kleen,
David Howells, linuxppc-dev, Greg Ungerer, sparclinux,
Miles Bader, Yoshinori Sato, Hirokazu Takata, linuxsh-shmedia-dev,
Grant Grundler, Linus Torvalds, Ivan Kokshaysky, Akinobu Mita,
Chris Zankel, dev-etrax, ultralinux, linux-kernel, linuxsh-dev,
linux390, parisc-linux
In-Reply-To: <20060129071242.GA24624@miranda.arrow>
On Sun, Jan 29, 2006 at 07:12:42AM +0000, Stuart Brady wrote:
> On MIPS, fls() and flz() should probably use CLO.
It actually uses clz.
> Curiously, MIPS is the only arch with a flz() function.
No longer. The fls implementation was based on flz and fls was the only
user of flz. So I cleaned that, once I commit flz will be gone. Not
only a cleanup but also a minor optimization.
Ralf
^ permalink raw reply
* Re: [RFC] arch/ppc/boot/simple/embed_boot.c : Merging all keyvals parsing code
From: Tom Rini @ 2006-01-30 17:28 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Dan Malek, linuxppc-embedded
In-Reply-To: <200601251702.20332.laurent.pinchart@tbox.biz>
On Wed, Jan 25, 2006 at 05:02:20PM +0100, Laurent Pinchart wrote:
> > > Should I submit a patch, or leave the code as it is ?
> >
> > Port Das U-Boot.
>
> Of course, that's another solution. We will use Das U-Boot for our custom
> design.
>
> What I wanted to do here is completely different. As the board comes with a
> proprietary boot loader, I thought it would be interesting for future users
> to have the board supported in the vanilla kernel, like many other boards
> are. Is that a mistake ?
No, that's good. If you can cleanly merge the existing parsing code, by
all means please do so. Thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* RE: MPC5200 - Problem with PSC mode
From: Zeitler, Nathan @ 2006-01-30 14:18 UTC (permalink / raw)
To: allanjos; +Cc: linuxppc-embedded
Hi Allann,
> out_8(&psc->command, MPC5xxx_PSC_RST_RX |
> MPC5xxx_PSC_RST_TX |
> MPC5xxx_PSC_SEL_MODE_REG_1 |
> MPC5xxx_PSC_RST_ERR_STAT);
It looks like you're trying to do too many things at once here. =20
ORing SEL_MODE_REG_1 and RST_ERR_STAT together=20
forms a completely different command in the Command=20
register. You may want to break that into two lines of code. =20
Give that a try!
Open Systems International, Inc.=20
Nathan Zeitler
Hardware Engineer
3600 Holly Lane North, Suite 40
Minneapolis, MN 55447-1286
Phone: 763 551 0559
Fax: 763 551 0750
E-mail: nzeitler@osii.com
^ permalink raw reply
* Re: [PATCH] remove check for ELF offset in powerpc bootimage
From: Simon Richter @ 2006-01-30 13:43 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Alan Modra
In-Reply-To: <20060130132803.GA31263@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]
Hi,
Olaf Hering wrote:
> Is this check really needed, are there PT_LOAD sections with offset
> zero (either zImage or vmlinux)? I see an offset which is always 64k.
Sure, an offset of zero is completely legal (obviously, the start
address would then be different from the load address of that segment).
Without context, I would say this loop is used to find some loadable
segment that does not include the ELF header. I cannot think of any
application for that, as it is certainly acceptable to merge LOAD
segments, and the segment it is looking for could have been merged with
the segment that includes the header.
If the current linker scripts specify that loading the header is
unneeded, this means that all LOAD headers will have nonzero offsets.
But I wouldn't count on that forever.[1]
Simon
[1] the Amiga bootloader, for example, assumes that all segments are to
be loaded, so things broke badly on APUS when the ldscript did not
remove the .note.gnu-stack section, which has a VMA of zero as it is
never loaded anyway. So depending on things being a particular way is
bad. :-)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Re: fs_enet not found in eldk
From: Vitaly Bordug @ 2006-01-30 13:53 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <ITWPNB$B571EC0EB15ACFD4C526E970D2B502FF@libero.it>
On Mon, 30 Jan 2006 14:04:23 +0100
"dibacco@inwind.it" <dibacco@inwind.it> wrote:
> I downloaded the latest kernel from denx.de but I cannot find fs_enet driver!
> Is it available for kernel 2.4?
>
> Thank you.
>
No, It is just available for 2.6 (and 2.6 denx tree does have it of course).
--
Sincerely,
Vitaly
^ permalink raw reply
* [PATCH] remove check for ELF offset in powerpc bootimage
From: Olaf Hering @ 2006-01-30 13:28 UTC (permalink / raw)
To: Alan Modra, Paul Mackeras, linuxppc-dev
Is this check really needed, are there PT_LOAD sections with offset
zero (either zImage or vmlinux)? I see an offset which is always 64k.
Do not check for offset, it is always set.
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/boot/main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.16-rc1-olh/arch/powerpc/boot/main.c
===================================================================
--- linux-2.6.16-rc1-olh.orig/arch/powerpc/boot/main.c
+++ linux-2.6.16-rc1-olh/arch/powerpc/boot/main.c
@@ -152,7 +152,7 @@ static int is_elf64(void *hdr)
elf64ph = (Elf64_Phdr *)((unsigned long)elf64 +
(unsigned long)elf64->e_phoff);
for (i = 0; i < (unsigned int)elf64->e_phnum; i++, elf64ph++)
- if (elf64ph->p_type == PT_LOAD && elf64ph->p_offset != 0)
+ if (elf64ph->p_type == PT_LOAD)
break;
if (i >= (unsigned int)elf64->e_phnum)
return 0;
@@ -193,7 +193,7 @@ static int is_elf32(void *hdr)
elf32 = (Elf32_Ehdr *)elfheader;
elf32ph = (Elf32_Phdr *) ((unsigned long)elf32 + elf32->e_phoff);
for (i = 0; i < elf32->e_phnum; i++, elf32ph++)
- if (elf32ph->p_type == PT_LOAD && elf32ph->p_offset != 0)
+ if (elf32ph->p_type == PT_LOAD)
break;
if (i >= elf32->e_phnum)
return 0;
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* fs_enet not found in eldk
From: dibacco @ 2006-01-30 13:04 UTC (permalink / raw)
To: linuxppc-embedded
I downloaded the latest kernel from denx.de but I cannot find fs_enet dri=
ver!
Is it available for kernel 2.4?
Thank you.
^ permalink raw reply
* Re: Question on USB gadget device driver for mpc 8272 on linux 2.6.14.
From: Mike Rapoport @ 2006-01-30 11:24 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060127154323.40e9404e@vitb.ru.mvista.com>
Vitaly,
Can you send me this patch?
Vitaly Bordug wrote:
>Jonathan,
>
>I have implemented the PQ2 usb-serial functionality a while ago, but the code needs a lot of cleanup, which is sometimes very tricky due to the tight timings required by this device. If you are interested, I can try to find the patch...
>
>On Fri, 27 Jan 2006 11:45:39 +1100
>"Jonathan Qiang" <jonathan@haliplex.com.au> wrote:
>
>
>
>>Hi, all
>>
>>Currently, I am doing on the USB gadget device driver for mpc8272, I
>>already got some packets on interruption route when my board in which
>>mpc82xx settled connect to Host.
>>But the SOF is always generated as the first interruption source. When
>>plugged USB cable in HOST, the USB controller will be set to reset
>>(USBER is [0x308]), and after reset, the interruption source event
>>changes its status to [0x108], which means running on IDLE and SOF. Why
>>It is not IN token?
>>I already disabled Frame timer when I probe the USB gadget controller.
>>
>>
>
>
>
>
--
Sincerely yours,
Mike Rapoport
^ permalink raw reply
* Re: Question on USB gadget device driver for mpc 8272 on linux 2.6.14.
From: Vitaly Bordug @ 2006-01-27 12:43 UTC (permalink / raw)
To: Jonathan Qiang; +Cc: linuxppc-embedded
In-Reply-To: <32A7B31E4005134E8BA805EBAAFB9DCD9C7A20@hellskitchen.haliplex.com.au>
Jonathan,
I have implemented the PQ2 usb-serial functionality a while ago, but the code needs a lot of cleanup, which is sometimes very tricky due to the tight timings required by this device. If you are interested, I can try to find the patch...
On Fri, 27 Jan 2006 11:45:39 +1100
"Jonathan Qiang" <jonathan@haliplex.com.au> wrote:
> Hi, all
>
> Currently, I am doing on the USB gadget device driver for mpc8272, I
> already got some packets on interruption route when my board in which
> mpc82xx settled connect to Host.
> But the SOF is always generated as the first interruption source. When
> plugged USB cable in HOST, the USB controller will be set to reset
> (USBER is [0x308]), and after reset, the interruption source event
> changes its status to [0x108], which means running on IDLE and SOF. Why
> It is not IN token?
> I already disabled Frame timer when I probe the USB gadget controller.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: HELP! Memory mapping and address space doubts
From: Vitaly Bordug @ 2006-01-27 13:37 UTC (permalink / raw)
To: Jose França; +Cc: linuxppc-embedded
In-Reply-To: <16FD2D70D281D44F9BFCF6ACF9B6117102AF731A@lisi053a.siemens.pt>
Jose,
Can you please be a bit more specific in targets you want to achieve?
An example how to setup br/or and use the device could be found as a part of PQ2 PCI support,
where interrupt controller is implemented as a CPLD device (arch/ppc/syslib/m82xx_pci.{c,h}).
On Thu, 26 Jan 2006 14:04:49 -0000
Jose França (Ext_GTBC) <Jose.Franca.Ext@siemens.com> wrote:
> Hello u all!
>
> I need to clarify some aspects of the memory management in ppc linux and i hope that you could help me.
> Lets imagine we have a mpc8272 based board with 3 devices A, B and C.In the bootloader (in my case, i use u-boot), i configured the BRx and Orx so that A has base address X, B has base address Y and C has base address Z. My first doubt arrises here: what address should i use? Being SDRAM base address 0x00000000 and kernel base address 0xC0000000, where will i put these devices mapped on? Above 0xC0000000 or in between the end of physical memory and 0xC0000000? Do i really need to configure the BAT registers in u boot?
> In linux 2.4 kernel, we have ppc_md.setup_io_mappings to map address blocks into the BAT registers... As i observed in the kernel source tree examples, we must map CPM (why?). And what about the other devices A, B and C? How will i setup them in this case and what addresses i can use? Above 0xC0000000 or in between the end of physical memory and 0xC0000000? Is the SDRAM included?
>
> Thanks in advance to all contributions! All of them will be most welcomed!
>
>
>
>
>
> Best regards,
> Filipe
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Qt, forks and threads = segmentation faults?
From: David Jander @ 2006-01-30 9:42 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Russell McGuire
In-Reply-To: <000301c623a2$13b98fc0$6405a8c0@absolut>
Hi Russell,
On Saturday 28 January 2006 01:30, Russell McGuire wrote:
> This is a more general question, and if anyone knows of a more specialized
> list this should be posted to, I'd be happy to do so...
>
> Small picture of hardware:
> DENX Linux 2.4.25 / PowerPC MPC8280 / 32 MBs of RAM
>
> I am using QT Embedded for a small GUI that does BSD sockets, also using
> DENX's SM501 video driver. Everything is quite stable, recently I added a
> additional process to the application using fork() for the listening
> 'accept' call for the sockets.
>
> After many tests I decided that due to the nature of the fork() command and
> the GUI half of the program, that this was a large waste of memory, as I
> was duplicating the entire GUI system. So I started looking alternatives,
> and have landed at the 'pthread' library.
It shouldn't be a waste of memory, since Linux uses copy-on-write for memory
pages. That means, although it looks like your child process wates a lot of
memory (same initial VSS size as parent), it actually shares its memory with
the parent until the child starts modifying memory contents (write fault
occurs). At that moment the page being written to is copied, and the write
access succeeds on the copied page. So fork() is nowadays quite efficient in
linux systems..... exactly as efficient as creating a thread.
> However, now I have lots of segmentation faults, particularly when I send a
> message using QT's postEvent commands back to the main thread.
Eeek. You might want to compile QT with thread support compiled in (don't know
if that helps though).
Anyway, it is probably a better idea to stick with fork() (see above).
> I was curious if anyone had any better idea of a more stable or perhaps a
> suggestion on why I am able to only get about 30 seconds of run time out of
> the app using pthread, verses fork() seems to be much stabler.
Use fork().
Greetings,
--
David Jander
^ permalink raw reply
* Re: [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: David S. Miller @ 2006-01-30 4:03 UTC (permalink / raw)
To: sdbrady
Cc: linux-mips, linux-ia64, spyro, ak, dhowells, linuxppc-dev, gerg,
sparclinux, uclinux-v850, ysato, takata, linuxsh-shmedia-dev,
grundler, torvalds, ink, mita, chris, dev-etrax, ultralinux,
linux-m68k, linux-kernel, linuxsh-dev, linux390, parisc-linux
In-Reply-To: <20060129071242.GA24624@miranda.arrow>
From: Stuart Brady <sdbrady@ntlworld.com>
Date: Sun, 29 Jan 2006 07:12:42 +0000
> There are versions of hweight*() for sparc64 which use POPC when
> ULTRA_HAS_POPULATION_COUNT is defined, but AFAICS, it's never defined.
That's right, the problem here is that no chips actually implement
the instruction in hardware, it is software emulated, ie. useless :-)
^ permalink raw reply
* Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Akinobu Mita @ 2006-01-30 3:29 UTC (permalink / raw)
To: Hirokazu Takata
Cc: akpm, linux-mips, linux-ia64, spyro, ak, dhowells, linuxppc-dev,
gerg, sparclinux, uclinux-v850, ysato, linuxsh-dev, torvalds, ink,
rth, chris, dev-etrax, ultralinux, linux-m68k, linux-kernel,
linuxsh-shmedia-dev, linux390, rmk, parisc-linux
In-Reply-To: <20060127.215147.670306403.takata.hirokazu@renesas.com>
On Fri, Jan 27, 2006 at 09:51:47PM +0900, Hirokazu Takata wrote:
> Could you tell me more about the new generic {set,clear,test}_bit()
> routines?
>
> Why do you copied these routines from parisc and employed them
> as generic ones?
> I'm not sure whether these generic {set,clear,test}_bit() routines
> are really generic or not.
I think it is the most portable implementation.
And I'm trying not to write my own code in this patch set.
>
> > +/* Can't use raw_spin_lock_irq because of #include problems, so
> > + * this is the substitute */
> > +#define _atomic_spin_lock_irqsave(l,f) do { \
> > + raw_spinlock_t *s = ATOMIC_HASH(l); \
> > + local_irq_save(f); \
> > + __raw_spin_lock(s); \
> > +} while(0)
> > +
> > +#define _atomic_spin_unlock_irqrestore(l,f) do { \
> > + raw_spinlock_t *s = ATOMIC_HASH(l); \
> > + __raw_spin_unlock(s); \
> > + local_irq_restore(f); \
> > +} while(0)
>
> Is there a possibility that these routines affect for archs
> with no HAVE_ARCH_ATOMIC_BITOPS for SMP ?
Currently there is no architecture using this atomic *_bit() routines
on SMP. But it may be the benefit of those who are trying to port Linux.
(See the comment by Theodore Ts'o in include/asm-generic/bitops.h)
> I think __raw_spin_lock() is sufficient and local_irqsave() is
> not necessary in general atomic routines.
If the interrupt handler also wants to do bit manipilation then
you can get a deadlock between the original caller of *_bit() and the
interrupt handler.
^ permalink raw reply
* Re: [PATCH 4/6] use include/asm-generic/bitops for each architecture
From: Akinobu Mita @ 2006-01-30 3:15 UTC (permalink / raw)
To: Hirokazu Takata
Cc: akpm, linux-mips, linux-ia64, spyro, ak, dhowells, linuxppc-dev,
gerg, sparclinux, uclinux-v850, ysato, linuxsh-dev, torvalds, ink,
rth, chris, dev-etrax, ultralinux, linux-m68k, linux-kernel,
linuxsh-shmedia-dev, linux390, rmk, parisc-linux
In-Reply-To: <20060127.220401.356433243.takata.hirokazu@renesas.com>
On Fri, Jan 27, 2006 at 10:04:01PM +0900, Hirokazu Takata wrote:
> compile and boot test on m32r: OK
Thanks.
> Code size became a little bigger... ;-)
>
> $ size linux-2.6.16-rc1*/vmlinux
> text data bss dec hex filename
> 1768030 124412 721632 2614074 27e33a linux-2.6.16-rc1.bitops/vmlinux
> 1755010 124412 721632 2601054 27b05e linux-2.6.16-rc1.org/vmlinux
The only difference I can find is __ffs()/ffz().
As Russel King clealy pointed out, it will generate larger code
than before.
^ permalink raw reply
* Re: Virtex-4 TEMAC device driver available?
From: David H. Lynch Jr. @ 2006-01-30 1:48 UTC (permalink / raw)
To: Yoshio Kashiwagi; +Cc: linuxppc-embedded
In-Reply-To: <JX2006011720543423.44411640@co-nss.co.jp>
Yoshio Kashiwagi wrote:
>Hi Patrick-san,
>
>GSRD of the following URL is downloaded and the driver of mvl is
>generated by EDK, the Xilinx temac driver and patch for 2.4 will be
>obtained.
>
>http://www.xilinx.co.jp/esp/wired/optical/xlnx_net/gsrd.htm
>
>Now, I'm just working temac driver to 2.6 and have not yet completed.
>
>Best Regards,
>Yoshio Kashiwagi - Nissin Systems
>
>
I could not get at the 2.4 driver at the url above.
How is the 2.6 driver going ?
Need any help ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net:8888
^ permalink raw reply
* Re: [PATCH] Add support for lite5200b board.
From: Sylvain Munaut @ 2006-01-29 22:21 UTC (permalink / raw)
To: John Rigby; +Cc: Txema Lopez, John Rigby, linuxppc-embedded
In-Reply-To: <4b73d43f0601261329n73971003n9217374a1cc2db6f@mail.gmail.com>
John Rigby wrote:
>
>
> On 1/25/06, *Sylvain Munaut* <tnt@246tnt.com <mailto:tnt@246tnt.com>> wrote:
>
>
>
> Should apply fine on vanilla. My suggestion for now is take vanilla,
> apply this patch, then the 2-3 patch from Andrey for BestComm and stuff.
>
>
> I was working on getting bestcomm and fec working, but forward porting
> my old 2.6.10 code to current is turning out to be more difficult than I
> expected.
> If you already have working code then I'll stop working on them.
>
> Where are these patches? I'm new to this list so I don't have much
> history.
> Would I find these patches in the archive?
Checkout (with git)
http://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx
then apply
http://gitbits.246tNt.com/patches/bcomm-to-split.diff
(I haven't cleanly splitted it up yet and right now I must go, so it's
probably gonna be in the git tree this week, under the 'bestcomm' head ;)
Please report if it works fine on your board (both lite5200 and
lite5200b reports are welcome). I only did quick tests.
Sylvain
^ permalink raw reply
* Re: MPC875 porting
From: Dan Malek @ 2006-01-29 21:47 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <ITVFT5$D7FAA0BB780EC8B8F02A50A5AB92E2E0@libero.it>
On Jan 29, 2006, at 3:34 PM, dibacco@@inwind..it wrote:
> I have a custom board with a MPC875 and two ethernet ports. I think I
> need to modify the enet.c to have two ethernet ports working.
Please read the archives and use the new drivers/net/fs_net
driver and the new serial port drivers. This has all been updated
and should just work for you.
Thanks.
-- Dan
^ permalink raw reply
* MPC875 porting
From: dibacco @ 2006-01-29 20:36 UTC (permalink / raw)
To: linuxppc-embedded
I have a custom board with a MPC875 and two ethernet ports. I think I nee=
d to modify the enet.c to have two ethernet ports working. What happens i=
f I define both
CONFIG_SCC1_ENET and CONFIG_SCC2_ENET ? I saw in enet.c the following cod=
e:
#if defined(CONFIG_SCC3_ENET)
#define CPM_CR_ENET CPM_CR_CH_SCC3
#define PROFF_ENET PROFF_SCC3
#define SCC_ENET 2 /* Index, not number! */
#define CPMVEC_ENET CPMVEC_SCC3
#elif defined(CONFIG_SCC2_ENET)
#define CPM_CR_ENET CPM_CR_CH_SCC2
#define PROFF_ENET PROFF_SCC2
#define SCC_ENET 1 /* Index, not number! */
#define CPMVEC_ENET CPMVEC_SCC2
#elif defined(CONFIG_SCC1_ENET)
#define CPM_CR_ENET CPM_CR_CH_SCC1
#define PROFF_ENET PROFF_SCC1
#define SCC_ENET 0 /* Index, not number! */
#define CPMVEC_ENET CPMVEC_SCC1
#else
#error CONFIG_SCCx_ENET not defined
#endif
The point is that there is and elif here, only the SCC1 will work then, I=
'm confused!
Thank you for your help!
Bye.
^ permalink raw reply
* MPC875 porting
From: dibacco @ 2006-01-29 20:34 UTC (permalink / raw)
To: linuxppc-embedded
I have a custom board with a MPC875 and two ethernet ports. I think I nee=
d to modify the enet.c to have two ethernet ports working. What happens i=
f I define both
CONFIG_SCC1_ENET and CONFIG_SCC2_ENET ? I saw in enet.c the following cod=
e:
#if defined(CONFIG_SCC3_ENET)
#define CPM_CR_ENET CPM_CR_CH_SCC3
#define PROFF_ENET PROFF_SCC3
#define SCC_ENET 2 /* Index, not number! */
#define CPMVEC_ENET CPMVEC_SCC3
#elif defined(CONFIG_SCC2_ENET)
#define CPM_CR_ENET CPM_CR_CH_SCC2
#define PROFF_ENET PROFF_SCC2
#define SCC_ENET 1 /* Index, not number! */
#define CPMVEC_ENET CPMVEC_SCC2
#elif defined(CONFIG_SCC1_ENET)
#define CPM_CR_ENET CPM_CR_CH_SCC1
#define PROFF_ENET PROFF_SCC1
#define SCC_ENET 0 /* Index, not number! */
#define CPMVEC_ENET CPMVEC_SCC1
#else
#error CONFIG_SCCx_ENET not defined
#endif
The point is that there is and elif here, only the SCC1 will work then, I=
'm confused!
Thank you for your help!
Bye.
^ permalink raw reply
* Re: [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h
From: Stuart Brady @ 2006-01-29 7:12 UTC (permalink / raw)
To: Grant Grundler, Akinobu Mita, linux-kernel, Ivan Kokshaysky,
Ian Molton, dev-etrax, David Howells, Yoshinori Sato,
Linus Torvalds, linux-ia64, Hirokazu Takata, linux-m68k,
Greg Ungerer, linux-mips, parisc-linux, linuxppc-dev, linux390,
linuxsh-dev, linuxsh-shmedia-dev, sparclinux, ultralinux,
Miles Bader, Andi Kleen, Chris Zankel
In-Reply-To: <20060126230353.GC27222@flint.arm.linux.org.uk>
On Thu, Jan 26, 2006 at 11:03:54PM +0000, Russell King wrote:
> Me too - already solved this problem once. However, I'd rather not
> needlessly take a step backwards in the name of generic bitops.
Indeed. However, I think we can actually improve bitops for some
architectures. Here's what I've found so far:
Versions of Alpha, ARM, MIPS, PowerPC and SPARC have bit counting
instructions which we're using in most cases. I may have missed some:
Alpha may have:
ctlz, CounT Leading Zeros
cttz, CounT Trailing Zeros
ARM (since v5) has:
clz, Count Leading Zeros
MIPS may have:
clz, Count Leading Zeros
clo, Count Leading Ones
PowerPC has:
cntlz[wd], CouNT Leading Zeros (for Word/Double-word)
SPARC v9 has:
popc, POPulation Count
PA-RISC has none. I've not checked any others.
The Alpha, ARM and PowerPC functions look fine to me.
On MIPS, fls() and flz() should probably use CLO. Curiously, MIPS is
the only arch with a flz() function.
On SPARC, the implementation of ffz() appears to be "cheese", and the
proposed generic versions would be better. ffs() looks quite generic,
and fls() uses the linux/bitops.h implementation.
There are versions of hweight*() for sparc64 which use POPC when
ULTRA_HAS_POPULATION_COUNT is defined, but AFAICS, it's never defined.
The SPARC v9 arch manual recommends using popc(x ^ ~-x) for functions
like ffs(). ffz() would return ffs(~x).
I've had an idea for fls():
static inline int fls(unsigned long x)
{
x |= x >> 1;
x |= x >> 2;
x |= x >> 4;
x |= x >> 8;
x |= x >> 16;
return popc(x);
}
I'm not sure how that compares to the generic fls(), but I suspect it's
quite a bit faster. Unfortunately, I don't have any MIPS or SPARC v9
hardware to test this on.
I'm not sure if this is of any use:
static inline int __ffs(unsigned long x)
{
return (int)hweight_long(x ^ ~-x) - 1;
}
The idea being that the generic hweight_long has no branches.
--
Stuart Brady
^ permalink raw reply
* MPC5200 - Problem with PSC mode
From: Moloko Vellocet @ 2006-01-28 23:02 UTC (permalink / raw)
To: linuxppc-embedded
Hi, I'm configuring a MPC5200 in PSC3 mode to communicate with a
telephony board that send information to the MPC5200 continuously. In
the osciloscope I see the signals comming via RX pin, but when I read
RX buffer it doesn't contain anything and when I write in the TX
buffer the flags show that buffer is not empty, but in the osciloscope
I don't see any signal in TX pin. I can't enable the interrupt mode
too.
Can anyone help me?
Part of the configuration code:
out_8(&psc->command, MPC5xxx_PSC_TX_DISABLE | MPC5xxx_PSC_RX_DISABLE);
val32 =3D in_be32(&gpio->port_config);
val32 &=3D ~0x700;
val32 |=3D 0x600;
out_be32(&gpio->port_config, val32);
out_8(&psc->command, MPC5xxx_PSC_RST_RX |
MPC5xxx_PSC_RST_TX |
MPC5xxx_PSC_SEL_MODE_REG_1 |
MPC5xxx_PSC_RST_ERR_STAT);
out_be16(&psc->mpc5xxx_psc_imr, 0);
out_be16(&psc->rfalarm, 0x0004);
out_be16(&psc->tfalarm, 0x0004);
out_be32(&psc->sicr, 0x221000);
out_8(&psc->command, MPC5xxx_PSC_RST_RX |
MPC5xxx_PSC_RST_TX |
MPC5xxx_PSC_SEL_MODE_REG_1 |
MPC5xxx_PSC_RST_ERR_STAT);
spin_lock_irqsave(&mpc5xxx_serial_lock, my_flags);
val16 =3D in_be16(&psc->mpc5xxx_psc_imr);
val16 =3D MPC5xxx_PSC_IMR_TXRDY | MPC5xxx_PSC_IMR_RXRDY;
out_be16(&psc->mpc5xxx_psc_imr, val16);
spin_unlock_irqrestore(&mpc5xxx_serial_lock, my_flags);
out_8(&psc->command, MPC5xxx_PSC_RX_ENABLE | MPC5xxx_PSC_TX_ENABLE);
So.. with this I tried to read the RX and write in TX buffer.
Thank you.
--
_______________________________
Allann J. O. Silva
"I received the fundamentals of my education in school, but that was
not enough. My real education, the superstructure, the details, the
true architecture, I got out of the public library. For an
impoverished child whose family could not afford to buy books, the
library was the open door to wonder and achievement, and I can never
be sufficiently grateful that I had the wit to charge through that
door and make the most of it." (from I. Asimov, 1994)
^ permalink raw reply
* Qt, forks and threads = segmentation faults?
From: Russell McGuire @ 2006-01-28 0:30 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.126.1138386609.857.linuxppc-embedded@ozlabs.org>
Everyone,
This is a more general question, and if anyone knows of a more specialized
list this should be posted to, I'd be happy to do so...
Small picture of hardware:
DENX Linux 2.4.25 / PowerPC MPC8280 / 32 MBs of RAM
I am using QT Embedded for a small GUI that does BSD sockets, also using
DENX's SM501 video driver. Everything is quite stable, recently I added a
additional process to the application using fork() for the listening
'accept' call for the sockets.
After many tests I decided that due to the nature of the fork() command and
the GUI half of the program, that this was a large waste of memory, as I was
duplicating the entire GUI system. So I started looking alternatives, and
have landed at the 'pthread' library.
However, now I have lots of segmentation faults, particularly when I send a
message using QT's postEvent commands back to the main thread.
I was curious if anyone had any better idea of a more stable or perhaps a
suggestion on why I am able to only get about 30 seconds of run time out of
the app using pthread, verses fork() seems to be much stabler.
-Russ
^ permalink raw reply
* Re: Yosemite/440EP why are readl()/ioread32() setup to read little-endian?
From: David Hawkins @ 2006-01-27 23:29 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200601261120.48251.sr@denx.de>
Hey Stefan,
>>readl() and ioread32() read the registers in little-endian format!
>
> Correct. That's how it is implemented on all platforms. Think for
> example of an pci device driver. Using these IO functions, the
> driver will become platform independent, running without
> modifications on little- and big-endian machines.
I just stumbled across the section in Rubini 3rd Ed that mislead
me into believing that the readl()/writel() were machine endianness
dependent, i.e., LE on x86, BE on PPC.
p453 of his book has a PCI DMA example, where he uses the
cpu_to_le32() macros inside calls writel().
However, since these functions are internally implemented to
perform LE operations, this example appears to be incorrect.
Would you agree?
I just checked the Oreilly web site for errata's and this is not
listed. If you agree that the example is incorrect, then I'll
submit an errata.
Dave
^ permalink raw reply
* RE: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
From: Clement Fabien @ 2006-01-27 18:09 UTC (permalink / raw)
To: Pantelis Antoniou, galak, Marcelo Tosatti, linuxppc-embedded
Hello Pantelis
What is the status for this patch - I did not see any approval in the
list.
For me it's ok and in "production" (except that I don't like the loss of
space but I can live with it)
Regards
Fabien
-----Original Message-----
From: Pantelis Antoniou [mailto:panto@intracom.gr]=20
Sent: jeudi 24 novembre 2005 12:04
To: Clement Fabien; Kumar Gala; Marcelo Tosatti; linuxppc-embedded
Subject: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
Hi all.
Alignments are currently handled bogusly for cpm2.
Please test.
Regards
Pantelis
^ 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