proposed patch for cross compiling from Solaris 2.8
On Tue, 6 Jul 2004, Jean-Christophe Dubois wrote: > Hi, > > I got into several issues while trying to cross-compile a Linux 2.6 PPC > kernel from a Solaris 2.8 host (beside getting a valid cross compilation > chain). Mainly some programs compiled on the host are not planned to be > compiled on anything but Linux (The host has to run Linux). All of the things you've changed look wrong to me. Most of your changes are taking out , which is not correct. This header should be on any system, it is part of the C standard. Even the getopt changes shouldn't be required, you should be using the version of getopt that came with your package. Are you sure that you've specified -nostdinc -nostdlib and given the proper list of locations for the cross-compile system includes when compiling? -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Hardware interrupts routines
On Wed, 16 Jun 2004, Mark Chambers wrote: > But isn't he going to have to write a device driver in order to call > request_irq()? He is going to have to write a loadable module, which may or may not have the normal driver entry points. If he is handling a PCI device, he definately should be writing a device driver. -Bret > You can't just call request_irq() from an application, can > you? That is correct. > If not, is there any way to grab an interrupt other than writing a > device driver? Any kernel code (i.e. loadable module) can call the routine. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Hardware interrupts routines
On Wed, 16 Jun 2004, [Windows-1252] Garcia J?r?mie wrote: [ nnip ] > The only hardware interrupts routine I found through my investigations > is the request_irq(...). But the problem is that request_irq do not > allow me to pass an argument to the handler... So is there a routine > that allows it or is there a way to adapt the request_irq() to my case. The last parameter of request_irq() gets passed as the second parameter to the interrupt routine when it is called. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
gcc version 2.95.3 20010315 (release/MontaVista) cross compiler
On Wed, 17 Dec 2003, David C. Chiu wrote: > > We're experiencing some unexpected behavior with binary generated with > the said version of gcc; namely that variables declared to char appear > to be defaulting to unsigned char. [ snip ] > Can someone shed some light on this? (As in, is this "normal" and we do > not know only because we've been living under a rock ;-) It is allowable by the specification. C89 allowed char to be either signed or unsigned, it was up to the implementation to decide which. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
General porting question
On Thu, 9 Oct 2003, Jacky Lam wrote: > Dear all, > > Could anyone give me some notes/idea what should be take care to port an > x86 PCI card driver to powerpc walnut platform? I try several > cards(ethernet, audio) which run well on my PC by cross-compiling the > drivers. They can be recognized successfully, but none of them works. Walnut > seems don't be able to receive any interrupt from the cards. > > I guess there must be something about PCI implementation in PPC > different from x86. Is there any expert on PPC PCI can tell me what happen? > Or any related documentation can help? Best guess, the driver doesn't handle any of the endian issues. PPC is a big-endian processor, x86 is little endian. Most likely you've got data that needs to be byte swapped in order to work. Best way I know of to find out if this is the case is using a PCI bus analyzer to watch the PCI bus. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Where to Put Ethernet MAC Addresses?
On Wed, 1 Oct 2003, Kent Borg wrote: > In boards where there is ethernet but no manufacturered in MAC address > in the ethernet hardware, where does one get it? Does this become a > userland problem to be handled in init scripts? It seems that > ethernet initialization could also set the "manufacturer" MAC address, > and it might be stored in flash next to the Linux image, or in some > extra SPD bits, etc. > > What are the various right ways to do this? Serial PROM. Check if the ethernet part allows reading the MAC directly from a small serial PROM. Many board manufacturers have processes for programming serial proms for this type of thing. Otherwise, just have the processor read the serial PROM and program it into the ethernet MAC. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Any restrictions on DMA address boundry?
Just wanted to thank both Matt Porter and Roland Dreier for taking the time to explain the situation. I've aligned our buffers to 32 bytes on PPC and am in the process of confirming the x86 snoop/coherency situation. Aligning it this way makes the transfer slightly faster anyways, since the 8245 PCI bridge will cause a disconnect at every 32-byte boundary on a PCI burst read. Since the work I'm doing is embedded and we use the same buffer format between application and driver/kernel space, I'm using a fixed number rather than L1_CACHE_BYTES. The define for L1_CACHE_BYTES is only available (as it probably should be) only if you've defined KERNEL. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Any restrictions on DMA address boundry?
On Thu, 25 Sep 2003, Eugene Surovegin wrote: > At 12:56 PM 9/25/2003, Matt Porter wrote: > >When a buffer is allocated using the allowed methods (as defined in > >DMA-mapping.txt) to obtain memory for use in DMA, there is > >no guarantee that the buffer is cacheline aligned. > > Hmm, I don't think this is true. > > DMA-mapping.txt explicitly states that pci_alloc_consistent() returns > aligned memory buffer: It has been cut from the conversation, but I'm using streaming DMA mappings. Specifically, pci_map_single() and pci_unmap_single(). My reading of the 2.4 DMA-mapping.txt is that use of pci_alloc_consistent() is specific to Consistent DMA mappings. Same for the pci_pool_ interface. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Any restrictions on DMA address boundry?
On Thu, 25 Sep 2003, Matt Porter wrote: > On Thu, Sep 25, 2003 at 01:15:15PM -0500, Bret Indrelee wrote: > > I've read through the old thread about short DMAs, but still there are > > things that aren't clear to me. > > > > What exactly is the issue? > > The issue is confined to processors which do not support hardware > snooping of the external bus. In this case, management of the > caches is performed in software. It is trying to figure out which systems have these sort of issues that I'm currently puzzling through. Where the heck should I expect to find this in the databooks for the various products? [ snip ] > > Right now, I'm interested in the PPC and x86 compatible (Pentium, > > Pentium 4, Geode) systems, trying to understand the differences and > > requirements of each. > > Which PPCs? Classic PPC != PPC8xx != PPC40x != Book E PPC. :) My immediate concern is 8245 and the Intel/Pentium style processors. In the near term for PPC, the 8245 and maybe 405E. > PPC8xx and PPC4xx require software cache coherency. If you want > your products to work on PPC44x (I hope you do, they are targetted > at markets where qlogic storage controllers are used) ensuring that > your DMA buffers are cacheline aligned at the head/tail is > important. It looked like on the PPC if I aligned for 32 byes (0x20), that should handle it for now. This is for embedded, not the HBA controller, so I shouldn't need to worry about CONFIG_PPC64BRIDGE. On Pentium, I have to figure out if they do the snooping or not. I suspect that they do, but finding cache coherency problems is bad enough that I need a more definitive answer than that. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Any restrictions on DMA address boundry?
On 25 Sep 2003, Roland Dreier wrote: > As I recall, the discussion ended with people like David Miller > agreeing that 2.6 would fix this in a better way, but that my patch > was OK for 2.4. However, unaligned DMA buffers only seem to cause > pain on non-mainstream platforms, so there was never much push to have > my patch merged in 2.4. I've never really pushed my patch since we've > fixed all the problems with our own specific embedded PPC 4xx > platform, and no one else seems to care very much. I've read through the old thread about short DMAs, but still there are things that aren't clear to me. What exactly is the issue? As I understand it, if there is a DMA to the same cache line as something that the CPU is referencing, you've got a cache problem. Does it matter what type of transfer the PCI device is doing? If it always does 32-bit burst memory write transfers instead of memory write & invalidate does that make a difference? Right now, I'm interested in the PPC and x86 compatible (Pentium, Pentium 4, Geode) systems, trying to understand the differences and requirements of each. Any insight into the details of the problem would be appreciated, on list or off. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Any restrictions on DMA address boundry?
Are there alignment restrictions on the address boundry your can start a DMA with when using the pci_map_single() / pci_unmap_single() calls? For some reason, I thought they had to be cache line aligned, but when I went back through the documentation I couldn't find any such restriction. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
IO, ANSI vs GCC structs
On Fri, 25 Jul 2003, Eugene Surovegin wrote: > At 12:22 PM 7/25/2003, Wolfgang Denk wrote: > > > accessed through a structure? Is it acceptable to do: > > > > > > #define MYHW (MY_MBAR+42) > > > > > > ... > > > > > > out_be32(MYHW, 0xco1df00d); > > > >...I would not accept such code. > > > >There is one fundamental difference: a field in a struct has a type, > >i. e. the compiler "knows" how big it is (8, 16, 32, ... bits), if > >special attributes apply (volatile), etc. > > Although functions like out_be32 also *know* the size :). > > IMHO, it's not a good idea to access IO remmaped registers simply through C > struct, it's better and safe to use out_* and in_*. Wouldn't best practices also include using a base address rather than a constant, so that when a new board places the hardware in a different location all you have to do is find it? out_be32(my_bar + offsetof(myregs_t, sna_reg), 0xdeadbeef); > There are issues that C struct cannot deal with - load/store reodering (of > course you can insert wmb() and friends if you know what you are doing :). > > I think the best practice is to use C struct (for readability) and > out_*/in_* on structure members for actual access. I've always written low level I/O routines for everything in a driver because it is easier to adapt when someone changes how they want to do access to the device. The code all calls the low level IO routines. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
IO, ANSI vs GCC structs
On Fri, 25 Jul 2003, Kent Borg wrote:
> The PPC arch likes to access physical devices with C structures that
> correspond to a memory map of device registers. But a colleague says
> that structure layout is not guaranteed. In fact, he cited two
> instances when he got burned by assuming he could predict structure
> layout. But neither of those examples were with GCC.
>
> Does GCC make guarantees beyond what ANSI requires? Is there some
> subtle detail that forces struct layout ("volatile" in the definition
> perhaps)?
There is nothing that guarentees this, in ANSI or GCC.
There are several things you can do which will work on all compilers I've
ever used (works in practice) and allow you to detect if the assumptions
are ever violated.
You can't use bit-fields. Don't even try.
You should always use fixed-width named types. I think you can use stdint
on most systems, when I started doing this there wasn't a common include
I could use everywhere so I ended up making my own.
What you basically want is the integer types uint8_t, uint16_t, uint32_t.
Make sure that the structure stays properly aligned, no 16-bit or 32-bit
quantities starting on an odd address or 32-bit quantities starting on
an address that isn't 4-byte aligned. Define your structures using
only these types. Make sure you put in filler for address space that doesn't
have registers in them. In your code, do a check on the sizeof() the
structure, make sure that it matches what you expect.
Example:
typedef struct mm_foobolizer {
uint8_t bar1;
uint8_t bar2;
uint16_t filler002; /* I use the offeset address in naming fillers */
uint32_t sna;
uint16_t fu;
uint16_t filler00a;
uint8_t buffer[0xa1];
uint8_t filler0ad;
uint16_t filler0ae;
uint32_t word_buf[0x100];
} my_reg_def_t;
#define EXPECTED_REG_SIZE 0x500
In your code, do the equivilent of:
assert(EXPECTED_REG_SIZE == sizeof(my_reg_def_t));
That should get you past the worst of the problems.
-Bret
--
Bret Indrelee QLogic Corporation
Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Best Linux/PPC compiler ?
On Fri, 16 May 2003, Steven Rothweiler wrote: > What is the best Linux/PPC compiler? > > Specifically, we're using MPC8270. We are coming from Linux/x86 > platform, where Intel has a nice compiler that blows the doors > off of gcc, performance-wise. I'm wondering if anyone knows if > there have been any studies comparing various Linux/PPC compilers. [ snip ] I don't know if you can do the cross-compiles, but xlc for AIX is the best PPC compiler I know of. You might try looking at SPEC, see what compilers have been used for SPECmark for various PPC systems. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
How ?
On Thu, 15 May 2003, Rakesh Jagota wrote: > Can anyone suggest me how we can invoke the interrupt generated in the > kernel from the user application. I am getting the interrupt in the driver, I > want to update some register in the application, when the inettrupt will be > generated, Right now I am using polloing method. Continuously I am calling > read routines. Don't know why you want to handle it from user space, but the easiest way to notify an application would be to send a signal. Have a special ioctl() to notify the driver that this application wants a signal, and then when the driver receives the interrupt it clears the condition and sends a signal to the registered application(s). -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Why my console output nothing
On Wed, 14 May 2003, Wolfgang Denk wrote: > in message <20030514152700.68497.qmail at eyou.com> you wrote: > > >Finally: did you order your BDI2000 yet? You will probably need it > > >soon. > > > > I know that,and I will try to persuade my "boss". > > Tell him that you are stuck and cannot continue without the right tool. It sometimes helps to do the math. Figure out how many days of engineering time you would have to save in order to pay for the BDI. In my experience, you've usually got at least one hardware and one software engineer working together to bring a board up, so it really doesn't take long to pay for it. If time to market means anything to your firm, or if others are depending on your completion before they can start working (you are on critical path for schedule), it becomes even easier to justify. We bought a couple, just so that there wouldn't be a problem finding one when you needed it for debug. The background debug is well worth the price. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Question about modules
On 4 Mar 2003, Ibon Gotxi Garcia wrote: > I understand that reason, and i'm not certain about the usefulness of > modules in embedded systems. Modules are generally easier to debug. > > Anyway, my original purpose was to develop the driver as a module, and > afterwards insert it into the kernel. I have just done it adding the > EXPORT_SYMBOL macro to commproc.c and listing it in export-objs in > arch/ppc/8xx_io/Makefile. Right, isn't it? > > Cheers. > > > > > Wolfgang Denk > > -- > Ibon Gotxi Garcia > > > -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
"printk" does not print
On Mon, 3 Mar 2003, Ing.Gianfranco Morandi wrote: > Hi to all, > > I'm trying to trace the execution path of a custom ISDN driver, and I have > used some printk() instructions to give some messages out. > > Now, everything is going well, but when I try to open the ttyI0 device (or > ttyIx it is the same) the printk() that I have placed into the file > isdn_tty.c does not print any messages. I am sure that such procedure has > been executed because I have placed a breakpoint on the "isdn_tty_open()" > and the program stopped. > > Anybody has an idea what happens? You probably neglected to set a KERN_ level. See if they are in your dmesg or messages file, you might be sending them to syslog but not the screen. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Drive, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Binary Compatibility of various flavors of PPC
On Mon, 13 Oct 2002, Kumar Gala wrote: > On Monday, October 14, 2002, at 01:15 PM, Matt Porter wrote: > > On Mon, Oct 14, 2002 at 12:13:52PM -0500, Mark Hatle wrote: > >> Bret Indrelee wrote: [ Looking to have compatible System and User binary image ] > >>> We are currently looking at the 405GPX, 8250, 8245, and PowerQUIC > >>> III. [ snip ] > >> If I was building a range of systems that required varying PowerPC > >> CPUs with a > >> common userspace I would stick to the 82xx/7xx/74xx families today. > > > > I'd have to agree with that. Classic PPC core implementations > > currently > > offer the broadest selection of userspace binary compatible processors. > > I agree, but it depends on how important floating point is to ones > userspace. If they do not care about FP then all of the PPC processors > 4xx/8xx/82xx/7xx/74xx/e500 all provide a compatible integer instruction > set. Float isn't important to us, we could have all float be emulated for as little of it we do. We need the bzImage.gz and RAM disk image have to be the same binary. The reason is simple, we don't want the customer to have the mess of 'which of these N firmware images do I need' when trying to upgrade. We want the whole line of products to use the same binary image. We want a process that uses lower power and board space processor than the Intel but still allows us to use the same binary across the line of products. Our best guess of the performance levels needed are going to be from about a 300MHz CPU to 800MHz or 1GHz. Having even higher performance options in the future would be a definate plus. -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Driver, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Binary Compatibility of various flavors of PPC
On Mon, 14 Oct 2002, Wolfgang Denk wrote: > In message localhost.localdomain> you wrote: > > We are trying to wade our way through the various processor choices and > > options available for PPC on Linux. > > > > One of our requirements is to be able to run the same binary image across > > a range of systems. The image can not change just because the processor > > does. > > > > We are currently looking at the 405GPX, 8250, 8245, and PowerQUIC III. > > What do you mean with "image"? > > Kernel Image? Application image (for example ramdisk with libraries > and application binaries)? Both combined? Both combined. A bzImage and RAM disk loaded off the boot media (Flash). -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Driver, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Binary Compatibility of various flavors of PPC
We are trying to wade our way through the various processor choices and options available for PPC on Linux. One of our requirements is to be able to run the same binary image across a range of systems. The image can not change just because the processor does. We are currently looking at the 405GPX, 8250, 8245, and PowerQUIC III. One thing we haven't been able to figure out is if the same PPC Linux system binary (including OS) can be configured to boot on any of these processors. It looks like the MMU changes when you go to Book E architechure (no BAT), but I'm not sure what some of the other differences might be. Can someone please tell me if it is possible to have an OS image that can boot any of the various PPC processors and adapt based on which processor model it is? Thanks, -Bret -- Bret Indrelee QLogic Corporation Bret.Indrelee at qlogic.com 6321 Bury Driver, St 13, Eden Prairie, MN 55346 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
