Re: Broken network for different u-boot compilation
Duy-Ky Nguyen wrote: Hello, I'm using u-boot 1.3.0 from the latest FreeScale Linux BSP MPC8313E-RDB. Wrong mailing list. Try mailto:[EMAIL PROTECTED] regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: request_irq issue
On Tue, Nov 4, 2008 at 7:38 PM, Laxmikant Rashinkar [EMAIL PROTECTED]wrote: Hi, I have a MPC8347 based board that runs linux-2.6.15.4 and 2.6.27.1. With the older Linux, my driver is able to successfully request_irq() interrupts 17, 18, 19, 20, 21, 22, 23 48. But with the newer linux, request_irq() works only for 17, 18 19. cat /proc/interrupts shows that none of the interrupts above are in use. Any pointers on why request_irq() is behaving thus? thanks for your help LK Search the mailing list archive. I've posted sample code for how to enable external interrupts, but it was probably around 2.6.19 time. I imagine the same issues still exist. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ELDK on 64-bit host
On Wed, Feb 20, 2008 at 10:03 AM, Kalle Pokki [EMAIL PROTECTED] wrote: Hi, I tried to copy the ELDK 4.0 installation I had to a new Core 2 Quad machine running 64-bit Ubuntu 7.10, but the new machine refuses to execute the cross compiler. Has anyone succeeded in running ELDK in this kind of environment? Yes (at least with 64-bit Debian on a single core Xeon), but you need a special library on the host. I think it's call 'ia32-libs'. It should be available via aptitude. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Endian problem when accessing internel regs on 8347
Hey Bruce, [EMAIL PROTECTED] wrote: __asm__ __volatile__(lwz%U1%X1 %0,%1; twi 0,%0,0; isync : =r (ret) : m (*addr)); They allow the compiler to use update and/or index mode for the memory operand. Well that makes sense, U for update and X for index, but I'm not sure they're applicable to this particular instruction and I'm not sure that the memory operand makes sense for PowerPC. Why not? Okay, after much digging and experimenting, I'll agree that the memory operand makes sense. When I first said that I was thinking of direct manipulation of memory, which the PPC doesn't support. (Don't ask, my brain sometimes goes off into la-la land without me :- ) Also, update mode is applicable and makes sense. But I do still have a problem with the index mode, though it could be compiler magic. Here's why: the index mode of the 'lwz' instruction requires three operands, i.e., 'lwzx rD,rA,rB', and there's only place holders for two operands. Is the compiler smart enough to add the third operand for the index mode? If so, what does it put for the third operand? Another question is how does the compiler know which mode to pick? And what is the significance of the trailing number? Some places in the code have %U1%X1 and others have %U2%X2? I've found documentation for the # and ## tokens, but I can't find anything for the %U or %X tokens. Now this has all been very interesting to learn but doesn't solve my underlying problem which I've finally drilled down to. At first I thought in_be32() might be broken because I wasn't getting back the value I knew to be in the internal register. I knew I had the address and the mapping to kernel space correct because I could use in_le32 and get the right value though it was byte swapped. The value in the register was 0xFFE7 but what I was getting from in_be32 was 0x. Then I started playing and here's what I found: Register value in_be32 value 0x12345678 0x1234567 0xff345678 0xff345678 0x5678 0x5678 0xf678 0xf678 0xfe78 0x 0xff78 0x This isn't an exhastive list but I tried about twenty values and pretty much what I found was that if bits 0 through 22 are set to 1 then in_be32 reads 0x. I've also tried it at a variety of addresses and the behaviour is the same. in_le32 works fine as does in_be16. I've got no ideas as to what may be wrong. I don't want to just arbitrarily point to that %U1%X1 parameter list, but I get compiler errors if I try to remove them so I can't prove or disprove it and I can't find any documentation on it I can't even form a theroy. Has anyone ever seen anything like this? Can't anyone suggest anything I can try? Are you sure that all the bits are configured as GPIO? Almost every peripheral pin on these chips is muxed at least two ways. Maybe some of the bits that you think are GPIO are configured as some other bus, possibly explaining goofy behavior and perceived volatility of data. This is pretty well-vetted code on a reasonably mature product, and in my experience it's very rarely the tools ... Just a thought. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Endian problem when accessing internel regs on 8347
Hi Bruce,
[EMAIL PROTECTED] wrote:
Hi,
I've got an MPC8347 running the 2.6.24-rc5 kernel and I'm trying to access
the GPIO registers. I already have a driver that's doing related work
(tho across PCI) and I just want to remap the internal CPU address to a
kernal address and be able to read/write the register using an IOCTL call
from user space. My problem is, every accessor I try does an endian
conversion before giving me my data. So here's some code snipits of what
I'm doing:
request_mem_region(0xec00, 24, my driver); // 0xec00 is the
memory mapped location of the GPIO regs
data_ptr2 = ioremap(0xec00, 24);
Then in the IOCTL function I try to read from the register. First I
tried:
ioread32(data_ptr2);
I know that the mapping is working okay because I got the data from the
GPIO direction register, but it's been byte swapped. The contents of the
register are 0xFFE7, but what my user space app gets back is
0xE7FF. I've tried all the varients I can find, readl(), inl(),
in_be32(), in_le32(), even __raw_readl(). They all give me back byte
swapped data. I'm very confused. Especially since I've looked at
in_be32() and in_le32(), they're both inline assembly, and they use
different instructions. They can't be giving me the same results. I'm
sure I'm not the first person to want to access PowerPC internal registers
through a driver. Can anyone give me a hint what I'm doing wrong?
As an additional question related to PowerPC inline assembly, can anyone
tell me what %U1%X1 means in the following:
__asm__ __volatile__(lwz%U1%X1 %0,%1; twi 0,%0,0; isync : =r (ret) :
m (*addr));
Thanks.
See 'ya!
Bruce
___
I've attached a poorly-written-yet-functional GPIO driver that I wrote a
while ago for the MPC8349 (same as what you have for all intents and
purposes). It uses in_be32() and out_be32().
Let me know if you have any questions.
regards,
Ben
/**
*
* gpio_driver.c
* Copyright Qstreams Networks 2006
*
* This file contains a simple Linux device driver for accessing GPIO ports
* It is originally targeted for the MPC8349 PowerQUICC II Pro processor,
* although with simple modifications it should work with lots of CPUs. Note
* that all CPU accesses are big-endian.
*
* History:
* 04/11/2006 BAW Initial Creation
*
*/
#include linux/init.h
#include linux/module.h
#include linux/ioport.h
#include linux/fs.h
#include linux/cdev.h
#include asm/io.h
#include asm/uaccess.h
#include gpio.h
struct gpio_dev {
struct gpio_reg *regs;
struct cdev cdev;
};
MODULE_AUTHOR(Ben Warren);
MODULE_LICENSE(GPL);
static int gpio_major_num;
static struct gpio_dev *gpio_devices;
static spinlock_t gpioLock[GPIO_NUM_BANKS];
extern phys_addr_t get_immrbase(void);
static u32 readGpioReg(u8 bank, u32 * addr)
{
u32 value;
spin_lock(gpioLock[bank]);
value = in_be32(addr);
spin_unlock(gpioLock[bank]);
return value;
}
static void writeGpioReg(u8 bank, u32 * addr, u32 val, u32 mask)
{
spin_lock(gpioLock[bank]);
out_be32(addr, (in_be32(addr) ~mask) | val);
spin_unlock(gpioLock[bank]);
}
/*
* Kernel-mode GPIO access functions.
* DO NOT CALL FROM USERSPACE
*/
int kgpio_set_dir(u8 bank, u8 bit, u8 isOutput)
{
u32 value = GPIO_BIT(bit);
if ((bank = GPIO_NUM_BANKS) || !gpio_devices) {
return -ENODEV;
}
writeGpioReg(bank, gpio_devices[bank].regs-gpxdir,
isOutput ? value : 0, value);
return 0;
}
EXPORT_SYMBOL(kgpio_set_dir);
int kgpio_get_dir(u8 bank, u8 bit)
{
u32 value;
if ((bank = GPIO_NUM_BANKS) || !gpio_devices) {
return -ENODEV;
}
value = readGpioReg(bank, gpio_devices[bank].regs-gpxdir);
return (value GPIO_BIT(bit) ? 1 : 0);
}
EXPORT_SYMBOL(kgpio_get_dir);
int kgpio_set_data(u8 bank, u8 bit, u8 isHigh)
{
u32 value = GPIO_BIT(bit);
if ((bank = GPIO_NUM_BANKS) || !gpio_devices) {
return -ENODEV;
}
writeGpioReg(bank, gpio_devices[bank].regs-gpxdat,
isHigh ? value : 0, value);
return 0;
}
EXPORT_SYMBOL(kgpio_set_data);
int kgpio_get_data(u8 bank, u8 bit)
{
u32 value;
if ((bank = GPIO_NUM_BANKS) || !gpio_devices) {
return -ENODEV;
}
value = readGpioReg(bank, gpio_devices[bank].regs-gpxdat);
return (value GPIO_BIT(bit) ? 1 : 0);
}
EXPORT_SYMBOL(kgpio_get_data);
int gpio_open(struct inode *inode, struct file *filp)
{
struct gpio_dev *dev;
/* Set things up so other methods can access private data */
dev = container_of(inode-i_cdev, struct gpio_dev, cdev);
filp-private_data = dev;
return 0;
}
int gpio_ioctl(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg)
{
int rc = 0;
gpioDataAccess gpioData = { 0, 0 };
struct gpio_dev *dev;
u8 bank;
/* Check that the caller really wanted GPIO */
if (_IOC_TYPE(cmd) != GPIO_IOC_MAGIC)
return -ENOTTY;
if (_IOC_NR
Re: Endian problem when accessing internel regs on 8347
[EMAIL PROTECTED] wrote: Ben Warren [EMAIL PROTECTED] wrote on 01/17/2008 07:01:10 AM: I've attached a poorly-written-yet-functional GPIO driver that I wrote a while ago for the MPC8349 (same as what you have for all intents and purposes). It uses in_be32() and out_be32(). Ben, Thanks for the answer. Hu, at first glance it looks like you're doing the same thing I am. Only difference I can see is you use get_immrbase() to figure out the address to ask for and I've got it hardcoded. Other than that we're both using request_mem_region() in in/out_be32(). Yet your's works for you and mine doesn't. Well, I'll take a closer look tonight and see if there's something you're doing that I missed. Unfortunately, I've gotten a higher level interrupt this morning and it may ba a day or so before I get back to this and can give you any feedback. Thanks again. See 'ya! Bruce Something else to consider is that I've never tried this beyond 2.6.19. Maybe things have changed since then. Anyway, glad to help if I can. cheers, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PowerPC Cross Compiler's Arch doesnt match
Hi Jeff, Jeff Parent wrote: I'm building a linux distro for work, that runs on embedded systems with either and ARM 9 or a PowerPC 603. I've had great luck building a cross compiler w/ crosstools and using them in the compiler jail created by Scratchbox. Now I am working on porting all my work to the PowerPC. When I build the cross compilers I have selected GCC-4.0.1 and GLIBC-2.3.5 for both setups. I create my jail in Scratchbox for the PowerPC and try compiling any of the GNU applications and when running the configure script I get: I have no idea what Scratchbox is, but when running gnu configure to cross-compile something, you typically need to supply the following switches: --host=powerpc-linux --build=i686 and CC will have to point to your cross compiler (e.g. export CC=powerpc-linux-gcc, or export CC=ppc_6xx-gcc, whatever your cross compiler is called). Of course, the values of these switches will depend on your setup, but this is what I use and I've built all sorts of packages from source. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Uboot and ML410
khollan wrote: John Hahn wrote: We are also using 3.81 make (Centos 5 distro) with ELDK 4.1 version downloaded from www.denx.de and have had no problems using the u-boot.zip srcs from www.xilinx.com/ml410_p, though we use uboot for our ml403 based development, we can build u-boot for ml403_config as well as ml410_config. Cheers John When I try compiling with my tools I get the message No rule to make target `hello_world.srec', needed by `all' Any way to work around this. I have compiled everything else I use on my system with these tools and it works fine. I did some research on this problem and it seemed to be a problem with the newer versions of make, but if thats not the case what is the problem? I don't really want to install ELDK to keep things consistent. Thanks Kevin This is an old problem that has been fixed in the U-boot make files for probably a year or so. If you can't upgrade U-boot, just comment out the 'examples' line in U-boot's main Makefile like this: SUBDIRS = tools \ # examples regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Semaphores in eldk4.1
HI Stuart, Stuart Hodgson wrote: Hi, I have been suing the eldk4.1 tool chain for a few months now and have not not encountered any problems with building until now. I build for two slightly different archs, ppc_85xx and ppx_82xx. The problem I have come up against is related to some of the semaphore functions in semaphore.h, namely sem_wait, sem_post. This was originally noticed in a third party driver I am porting from one board to another but a small test program has shown the same results. Calls to these functions on the ppc_82xx platform return -1 with an error code of 38, in this case meaning ENOSYS (not implemented). On the ppc_85xx the same program executes fine, thus I conclude that it is specific to the libc-2.3.5 for ppc_82xx. Has anyone else come across this problem, I did find one thread but there was no conclusion listed. These work fine for me with ppc_6xx architecture and ELDK 4.1, although they didn't with ELDK 4.0. In that case, I was getting ENOSYS on sem_open() and sem_init(). Do these functions return 0 for you? I assume you're using a kernel that supports POSIX semaphores (I think that started at 2.6.12) and that you're using the glibc version of ELDK and not ulibc. I also can not find anything stating that these functions are not implemented for the 82xx arch compared with others for the eldk4.1 Thanks Stuart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: SPI driver for spi_mpc83xx
Fabio,
Note: I've changed the e-mail subject back to the original. In the
future, please ensure that it remains intact.
fabio777 wrote:
Thanks Ben,
Here it is
static struct fsl_spi_platform_data k_platform_data = {
.initial_spmode = 0,
.bus_num = 1,
Probably should be bus_num = 0
.max_chipselect = 1,
/* board specific information */
.activate_cs = k_cs_activate,
.deactivate_cs = k_cs_deactivate,
.sysclk = 266,
};
static struct spi_board_info spi_board_info[] __initdata = { {
.modalias = kplus,
.platform_data = k_platform_data,
.max_speed_hz = 12,
.bus_num = 1,
Again, bus_num probably should be 0
.chip_select = 0,
},
};
struct platform_device k_plus = {
.name = kplus,
name should be mpc83xx_spi. At initialization, the SPI controller
driver searches the registered platform devices (models of board
hardware) for a match. Without a match, it gives up.
.id = 1,
.dev = {
.platform_data = k_platform_data,
},
};
platform_device_register(k_plus);
Do you add the SPI controller's resources (base address and IRQ?) You'll
need to in order for this to work. On my board, I use
'platform_device_register_simple()', passing the name and the two
resources, then call 'platform_add_data()', passing in the platform data
structure.
spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info))
Good
and then calls spi_register_driver(k_driver);
I don't think this last call is needed.
I can't get the into the *probe functions.
Thanks
regards,
Ben
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: SPI driver for spi_mpc83xx
fabio777 wrote: Has anyone been using this driver ? I use it, on ARCH=powerpc, though. For legacy reasons I need to keep the ppc=arch however I haven't found out how to get this driver probed at start-up even basing my init on Lublock. The driver's expecting a platform device with name mpc83xx_spi to be registered in board init code. If you post your init code I may be able to help. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC85xx and linux IDE driver
Michael Brian Willis wrote: On Wed, 2007-10-17 at 14:44 -0400, Ben Warren wrote: This device driver is a platform driver, so you need to register a platform device somewhere in your board-specific init code that contains the hardware details (memory mapping and IRQ #). After modifying your init code and putting it in my board specific .c file everything is working great. Fantastic! Thanks again for all of your help! You're welcome. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC85xx and linux IDE driver
Michael Brian Willis wrote:
On Fri, 2007-10-12 at 15:48 -0400, Ben Warren wrote:
Here's what I use:
http://marc.info/?l=linux-kernelm=113877891224982w=2
Thanks for the response Ben.
I have put the driver you mentioned in my linux source and added the
necessary information in the Kconfig file and the Makefile. So, I am now
able to build the driver when I make my kernel image. However, I can't
figure out what else needs to be done in order to actually use the
driver for my compact flash device. Do I need to specify anything at the
kernel command line, or do I need to modify any other config files?
(Below is the ide portion of my linux .config file)
This device driver is a platform driver, so you need to register a
platform device somewhere in your board-specific init code that contains
the hardware details (memory mapping and IRQ #). You can either pass
this in via device tree or hard code it. I chose the latter in order to
get up and runninq quickly. Here's the init function I use. CS0 is @
0xe400, CS1 is @ 0xe410 and I'm using IRQ20, which is one of the
external IRQs on my CPU:
/* Compact Flash Initialization */
static int __init prism_setup_cf(void)
{
struct resource r[3];
struct platform_device *cf_dev;
unsigned int virq;
memset(r, 0, sizeof(r));
r[0].start = 0xe400;
r[0].end = 0xe40f;
r[0].flags = IORESOURCE_MEM;
r[1].start = 0xe410;
r[1].end = 0xe41f;
r[1].flags = IORESOURCE_MEM;
virq = irq_find_mapping(NULL, 20);
set_irq_type(virq, IRQ_TYPE_EDGE_FALLING);
r[2].start = virq;
r[2].end = 0;
r[2].flags = IORESOURCE_IRQ;
cf_dev = platform_device_register_simple(mmio-cfide, 0, r, 3);
return (cf_dev ? 0 : PTR_ERR(cf_dev));
}
Thank you for your help so far, anymore help/direction is greatly
appreciated.
Glad to help.
regards,
Ben
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC85xx and linux IDE driver
Michael Brian Willis wrote:
Hello,
I am using an MPC8540 based embedded system with a Compact Flash card in
true IDE mode. The Compact Flash card is directly connected to the
MPC8540 bus without the use of a pcmcia adapter.
The Compact Flash card is being initialized correctly using the U-boot
boot-loader and is working properly as an ide device in U-boot. However
I cannot get linux to recognize the ide device.
I have tried several different linux config options and have tried
passing kernel command line options as advised in the
Documentation/ide.txt help file. However I have not been able to get the
kernel to recognize my ide device.
Does anybody know if I can use the generic linux ide drivers? Or will I
need to modify/write my own driver for this type of setup?
Here's what I use:
http://marc.info/?l=linux-kernelm=113877891224982w=2
Please note that if you're using a kernel newer than 2.6.18, the _insw()
and _outsw() calls no longer exist, so you'll need to replace them.
Here's how I modified Kumar's functions. Not necessarily the right way,
but it seems to work:
/* xxx: use standard outsw, insw when byte lanes swapped */
static void cfide_outsw(unsigned long port, void *addr, u32 count)
{
u16 *tmp = addr;
while (count--)
out_le16((u16 *)port, *tmp++);
}
static void cfide_insw(unsigned long port, void *addr, u32 count)
{
u16 *tmp = addr;
while (count--)
*tmp++ = in_le16((u16 *)port);
}
regards,
Ben
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add platform support for the MPC837x RDB board
Mark A. Greer wrote: On Thu, Sep 27, 2007 at 04:28:30PM -0500, Olof Johansson wrote: On Thu, Sep 27, 2007 at 03:03:12PM -0500, Josh Boyer wrote: On Thu, 27 Sep 2007 12:53:51 -0700 Mark A. Greer [EMAIL PROTECTED] wrote: On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote: Thanks for the advice, but I was just basing the list to post to on the MAINTAINERS file which states that this is the one for Embedded PPC83XX. If you still think that I should post to linuxppc-dev, let me know. Yes, I think it would be better to repost to linuxppc-dev. Does anyone have an objection to changing all of the: L: linuxppc-embedded@ozlabs.org in MAINTAINERS to: L: [EMAIL PROTECTED] ?? Kumar, Josh, Vitaly, et. al.? I personally don't care either way. I'm already subscribed to both lists. Makes sense to go to linuxppc-dev given the arch/powerpc migration. I thought the -embedded list was created in the first place to keep some of the noise off of -dev (i.e. I can't get interface foo to work on my custom embedded eval board-lookalike board, HELP!). If people still care about keeping that on a separate list, then we shouldn't change it. Yes, IIRC, that was the reason but now with the merge and low volume on this list, it makes sense to me to just get rid of -embedded. Perhaps my perspective is unique, but I doubt it. I find it nice that this list is low volume and not filled with endless patches about CHRP and P series and open firmware syntax blah blah blah... No offense intended to all the people who are doing wonderful work expanding the Linux universe, but for your average dude or dudette working on embedded boards that happen to have a PowerPC processor, this list is a pretty good forum. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add platform support for the MPC837x RDB board
Josh Boyer wrote: On Mon, 01 Oct 2007 15:49:22 -0400 Ben Warren [EMAIL PROTECTED] wrote: Mark A. Greer wrote: On Thu, Sep 27, 2007 at 04:28:30PM -0500, Olof Johansson wrote: On Thu, Sep 27, 2007 at 03:03:12PM -0500, Josh Boyer wrote: On Thu, 27 Sep 2007 12:53:51 -0700 Mark A. Greer [EMAIL PROTECTED] wrote: On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote: Thanks for the advice, but I was just basing the list to post to on the MAINTAINERS file which states that this is the one for Embedded PPC83XX. If you still think that I should post to linuxppc-dev, let me know. Yes, I think it would be better to repost to linuxppc-dev. Does anyone have an objection to changing all of the: L: linuxppc-embedded@ozlabs.org in MAINTAINERS to: L: [EMAIL PROTECTED] ?? Kumar, Josh, Vitaly, et. al.? I personally don't care either way. I'm already subscribed to both lists. Makes sense to go to linuxppc-dev given the arch/powerpc migration. I thought the -embedded list was created in the first place to keep some of the noise off of -dev (i.e. I can't get interface foo to work on my custom embedded eval board-lookalike board, HELP!). If people still care about keeping that on a separate list, then we shouldn't change it. Yes, IIRC, that was the reason but now with the merge and low volume on this list, it makes sense to me to just get rid of -embedded. Perhaps my perspective is unique, but I doubt it. I find it nice that this list is low volume and not filled with endless patches about CHRP and P series and open firmware syntax blah blah blah... No offense intended to all the people who are doing wonderful work expanding the Linux universe, but for your average dude or dudette working on embedded boards that happen to have a PowerPC processor, this list is a pretty good forum. I think the original thought was to have patches go to linuxppc-dev. Not necessarily all discussion. josh True, and that makes sense. Patches should go where the right people will see them quickly. At least two people have advocated getting rid of the linuxppc-embedded list, though. Maybe I misunderstood. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: U-Boot problems with MPC8272ADS
Manil Gaouar wrote: Hi all, I have been trying many things to solve this problem, I found using a JTAG that U-Boot is running from flash so my JP9 jumper should stay in BCSR. This is off-topic here. Please re-post to the U-boot mailing list, and try to be more concise: mailto:[EMAIL PROTECTED] regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Flash on ep8248e standard motherboards
Erik Christiansen wrote: On Tue, Sep 04, 2007 at 12:08:47PM -0600, Alan Bennett wrote: BDI 2000 Config File: ; initialize - FLASH BR0 OR0 (64 Mbyte) ;*** WM320xf0010100 0xfc001801 WM32 0xf0010104 0xfc0008c2 [FLASH] CHIPTYPEMIRRORX16 CHIPSIZE0x200 BUSWIDTH16 Having just taken delivery of an ep8248e, I'm surprised that the supplied flash config is commented out and erroneous: [FLASH] ;CHIPTYPEAM29F ;Flash type (AM29F | AM29BX8 | AM29BX16 | I28BX8 | I28BX16) ;CHIPSIZE0x20;The size of one flash chip in bytes (e.g. AM29F010 = 0x2) ;BUSWIDTH8 ;The width of the flash memory bus in bits (8 | 16 | 32 | 64) ; Did you start with the Embedded Planet offering, in your current effort to create a usable config? Is MIRRORX16 more than a guess? I've found that my flash chips are spansion GL256N10FFI02, which AFAICT are S29GL256N10FFI02 from AMD, as we used to know them. I wonder if S29M32X16 is a likely guess for CHIPTYPE on the card which has landed in my lap? MIRRORX16 is the correct type for Spansion GL series NOR flash. AMD spun off their flash business a while ago and renamed it Spansion. If you look on the datasheet you'll see that Spansion calls the GL technology 'MirrorBit', and in all likelihood the device has a 16-bit data bus. The AMD algorithm may work but the MIRRORX16 definitely will. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ping command
Nethra, On Wed, 2007-07-25 at 02:29 -0700, Nethra wrote: hi, I m using custom board same as eval board MPC8272ADS board. IP assigned for both ethernets are... ifconfig eth1 192.168.33.135 up ifconfig eth1 netmask 255.255.248.0 route add default gw 192.168.32.47 eth1 ifconfig eth0 192.168.178.89 up ifconfig eth0netmask 255.255.255.0 route add default gw 192.168.178.47 eth0 but if i try for ping 192.168.33.135 command pails by the server of 178 series similarly ping 192.168.178.89 command pails by the server of 33 series.. what is the problem..and whre i m going wrong..? What does your routing table show? (route -n). It wouldn't hurt to also post the output of ifconfig for both interfaces. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 83xx: requesting external interrupts
Hi Jocke,
On Fri, 2007-06-29 at 13:34 +0200, Joakim Tjernlund wrote:
snip
I too am adding such a IRQ for my PHY connected to external IRQ2.
The PHY is connetced to UCC2.
I have this in my DTS for the PHY:
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
reg = 2320 18;
device_type = mdio;
compatible = ucc_geth_phy;
phy1: [EMAIL PROTECTED] {
interrupt-parent = ipic;
interrupts = 12 2; //EXT IRQ2
reg = 0; // 0
device_type = ethernet-phy;
interface = 3; //ENET_100_MII
};
Now the things is that the IRQ works with and without the
/* All external IRQs + Generic timer IRQs must be initialized by BSP */
const int bsp_irqs[] = {48, 17, 18, 19, 20, 21, 22, 23, 90, 78, 84, 72};
for (i=0;isizeof(bsp_irqs)/sizeof(bsp_irqs[0]);i++)
virq = irq_create_mapping(NULL, bsp_irqs[i]);
code in my bsp. There is one difference though.
Printing the irq num in phy_interrupt:
static irqreturn_t phy_interrupt(int irq, void *dev_id)
{
struct net_device *dev = (struct net_device *)dev_id;
struct ucc_geth_private *ugeth = netdev_priv(dev);
ugeth_vdbg(%s: IN, __FUNCTION__);
printk(KERN_ERR PHY IRQ:%d \n, irq);
Shows a difference:
with the bsp code added it prints:
PHY IRQ:18
and when I remove the bsp code it prints:
PHY IRQ:19
So what is correct, should I add the bsp code or not?
Jocke
I had to add this board initialization code because on my CPU (8349),
certain interrupts weren't automatically mapped by built-in kernel code.
Interrupts simply weren't firing, because they hadn't been enabled in
the IPIC. Your case is different, because the MDIO device tree entry is
parsed by common code (arch/powerpc/sysdev/something).
You probably don't need to explicitly map IRQs unless they're being used
by custom device drivers. I don't know why you'd get a different
virtual mapping, though. I guess you're effectively mapping the same
IRQ twice, and I don't know what that does. Part of me wants to say if
it works properly, who cares, but that's how we get into trouble...
Somebody like Kumar Gala could probably provide a real answer.
regards,
Ben
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Making fs_enet phy unaware
Hi Antonio, On Mon, 2007-06-11 at 12:30 +0200, DI BACCO ANTONIO - technolabs wrote: Hi all, how can I avoid that fs_enet driver uses its associated phy? My problem is that my FEC is attached to a switch and three other ports of the switch are connected to three physical connectors. I don't want that the driver bothers about the PHYs. If you search the archives you'll find patches by Vitaly Bordug and Andy Fleming for so-called 'Fixed PHY'. I've been using this for quite a while and it works quite well. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Kernel 2.6, ML403, rootfs on nfs, gigabit ethernet link, nfs mount problems
Hi Mohammad, On Tue, 2007-05-29 at 14:41 +, Mohammad Sadegh Sadri wrote: Hi all, well I could bring up the grant's kernel on ml403 completely. the root file system was over nfs. when I use a 100mbits link for connection to ml403 , every thing is working suitably. but when I use a 1000mbits link, I see that ml403 gets ip address from dhcp and mounts the root file system but can not go further , it stops with a message: nfs server not responding some thing like this. when pinging to ml403 with 64 bytes packets, ping works fine for both of 100 and 1000mbits links but when I try to ping the board with 4000 bytes packets I notice that ml403 on gigabit link can not answer to ping packets, however on 100mbit link every thing works just fine. any ideas? NFS is notorious for sending lots of big packets one right after another. This can easily overwhelm an Ethernet receiver. Until you're able to figure out why the 1000M link can't keep up, limit the NFS receive packet sizes by passing the following NFS option in your kernel command line: rsize=1024 You can experiment with the value. I believe the NFS default size is typically 8kB or greater. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 83xx: requesting external interrupts
Alex,
On Fri, 2007-05-11 at 10:29 +0100, Alex Zeffertt wrote:
Hi,
Thanks for your reply Ben, but I think my problem is slightly different. It
is not
that the sense (high/low/rising/falling) of the interrupt is wrong, but that
the
kernel will not allow me to register the handler.
I've changed my code to:
struct device_node *np = of_find_node_by_type(NULL, ipic);
struct irq_host *host = irq_find_host(np);
int rc;
unsigned int virq = irq_find_mapping(host, 5);
set_irq_type(virq, IRQ_TYPE_EDGE_FALLING);
rc = request_irq(virq, mpc832xemds_phy_interrupt, IRQF_SHARED, pm5384,
dev);
but the last line still returns a non-zero error code.
Is there a new way of requesting to install a handler for external
interrupts? I
can't find any powerpc examples in the kernel tree
Sorry, I missed a bit of the implementation. You need to register the
IRQs before attempting to attach an ISR. Here's some sample code that
works for me. You'll probably need different IRQs, based on what your
board does:
/* All external IRQs + Generic timer IRQs must be initialized by BSP */
const int bsp_irqs[] = {48, 17, 18, 19, 20, 21, 22, 23, 90, 78, 84, 72};
Add this to your BSP IRQ init code (void __init xxx_init_IRQs())
for (i=0;isizeof(bsp_irqs)/sizeof(bsp_irqs[0]);i++)
virq = irq_create_mapping(NULL, bsp_irqs[i]);
That should do it.
regards,
Ben
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 83xx: requesting external interrupts
On Fri, 2007-05-11 at 15:15 -0500, Kumar Gala wrote: I assume you're code doesn't look exactly like this. You'll need to use the virq in the request_irq()... its most likely just random luck if things are working and you aren't using the virq returned from irq_create_mapping() (Well its more than random luck, its because most 83xx systems only have one PIC and this hw_irq # == virq) - k In the code that registers the ISR I do this: virq = irq_find_mapping(NULL, MY_IRQ); request_irq(virq ...) Since I only have one interrupt controller, host is NULL, right? regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 83xx: requesting external interrupts
Alex, Follow this thread... http://marc.info/?l=linuxppc-embeddedm=116849062702002w=2 On Thu, 2007-05-10 at 17:45 +0100, Alex Zeffertt wrote: Hi list, I'm trying to port a driver from 2.6.11 to 2.6.21 and I'm stuck on the following line: request_irq(MPC83xx_IRQ_EXT5, mpc832xemds_phy_interrupt, SA_SHIRQ, pm5384, dev); The first problem is that MPC83xx_IRQ_EXT5 is no longer defined. If I hard code this to what I think is the right value (i.e. 21) then request_irq fails on insmod. I obviously need to do something different now that ARCH=powerpc, but I can't find any examples of code which requests 83xx external interrupts. Can anybody help? TIA, Alex ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: POSIX semaphores on ppc_6xx
Thanks Arnd, --- Arnd Bergmann [EMAIL PROTECTED] wrote: On Friday 20 April 2007, Ben Warren wrote: The cross-compiled glibc that is included in ELDK 4.0 doesn't seem to have support for POSIX semaphores. I get the following runtime errors: sem_open: Function not implemented when trying to implement a named semaphore, and sem_init: Function not implemented when trying to implement an unnamed semaphore. Does anybody know if POSIX semaphores have been ported to ppc_6xx, and if so, where I could find a binary copy? This normally works in every modern glibc. Maybe you were using an set of kernel headers that is too old. Make sure that you have up-to-date version of both kernel and glibc and that you use the kernel header files you get from 'make headers_install' in the kernel. Arnd I haven't had a chance to try this out yet, but appreciate your tip! regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Multiple Boards with same MAC addresses - problem.
Zhivko, On Tue, 2007-04-10 at 16:51 +0200, powerpc440 wrote: Hello all, I have multiple boards, based on ppc405ep (which include on-chip two ethernet ports). I'm configure the MAC address in u-boot and all works great. The problem appears when I use two or more boards in one network, because the MAC addresses are the same. Now I'm making a own u-boots for each board, but this solution is not very comfortable. My question is, which is the standard way to resolve such problem? I would have only one generic u-boot. Is this possible? Best regards, Zhivko Yordanov Please post to the U-boot mailing list. There's no reason why you should need to custom build for each board. You need to create some kind of board calibration procedure where each board is assigned a unique MAC address, and then save it in U-boot. If your problem is that your unique U-boot MAC addresses don't make it to Linux, the people on the U-boot list can give you direction. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Unable to Boot 2.6.19.2 from ELDK 4.1 on MPC8349E MDS
Gary,
--- Gary Kenaley [EMAIL PROTECTED] wrote:
I have been evaluating Freescale 2.6.11, Wind River
2.6.14, and am now
attempting Denx 2.6.19 (from ELDK 4.1) - running on
the Rev 1.0 MPC8349E
MDS (V1.1 CPU). I boot 2.6.19.2 using the factory
u-boot 1.1.3 and the
kernel immediately hangs:
Uncompressing Kernel Image ... OK {hangs forever}
This version of U-boot is very old. It is too old to
boot a Linux kernel that was built using ARCH=powerpc.
On to your questions...
snip
Questions, please:
--
1. Should I expect this kernel to boot on the
MPC8349E MDS, or do I need
to find and apply a variety of patches?
This kernel will boot on this board (I have the same
board), but you need to do a few things:
1. Get the latest U-boot. It's available via git
from:
git://www.denx.de/git/u-boot.git.
2. Get 'dtc', the device tree compiler. It's
available at www.jdl.com
3. Compile the device tree file for your board, which
is in /arch/powerpc/boot/dts/mpc8349emds.dtc of the
Linux source.
4. From U-boot, load the .dtb file that was generated
in step 3 either into memory or flash.
5. Modify whatever U-boot command you're using to boot
Linux to call 'bootm kernel address - dtb address
6. Try to not get frustrated about this device tree
stuff. It's not very well documented, but several
people recognize this and are working to remedy it.
2. Any idea why I have problems doing the ELDK 4.1
full source rebuild
from scratch?
Can't comment. I'm still on ELDK 4.0.
3. Do you see anything else important that I should
change in my
process?
Since I am a bit of a newbie, I'll be grateful to
get a lot of specific
advice.
Thanks, Gary
Feel free to ping the U-boot list if you need help.
It's very possible that I missed something here or
wrote something incorrectly. Please ask again if you
still have difficulty.
regards,
Ben
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Reset cause API
Hello, Is there an API call, either Linux or PowerPC-specific, for determining the cause of the last reset? I can certainly read the RSR myself, but why bother if the information's available elsewhere. thanks, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Kernel support for the TI1520 PCI-CardBus bridge?
Bruce, --- [EMAIL PROTECTED] wrote: Hi all, We're designing a new product and we want to put a CF card in it. We're thinking the easiest way to do that is to put in a PCI-CF bridge and we would like to use the TI1520 because it's industrial rated which we need. We can get the parts but TI is refusing to give us any support because they're devoting 100% of their time to dealing with the Vista release. I'm curious if anyone has ever successfully gotten this part to work in linux. I found it listed in pci_ids.h, but that doesn't mean it's actually used/working. I'm not looking for a detailed explination right now, we're just trying to gage if this part would be a couple of weeks of work or a couple of months. Thanks for any info. If you don't need hot-plugging and happen to be using either a Freescale PowerQUICCx or IBM/AMCC 4xx chip, you might consider connecting directly to the local bus and operating in TrueIDE mode. This has limitations, but has been done many times. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] jffs2 file system
On Thu, 2007-02-22 at 20:28 -0800, Nethra wrote: thanks... what are the steps to create jffs2 image? Here's a good link on building a JFFS2 filesystem: http://www.denx.de/wiki/view/DULG/RootFileSystemOnAJFFS2FileSystem do i need to disable nfs option in kernel? No. Both can happily co-exist what r steps for jffs2 mounting after nfs mounting on the board? Try: mount -t jffs2 -o ro /dev/mtdblockX /mount_path I'd recommend booting to an NFS filesystem. Once in Linux, you can try mounting the JFFS2 block and debug from there. Once you have that working, try booting to JFFS2 via the MTD_PHYSMAP methods. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC834x global timers question
Bruce, --- [EMAIL PROTECTED] wrote: I know this isn't the right forum for this but I can't seem to find a generic PPC mailing list. I'm trying to get a global timer going on an MPC834x, and the way I learn is to just play with HW, so I've got an Abatron BDI2K hooked up to my processor so I can just manipulate registers without having to deal with writing code. However, I seem to be unable to modify certain registers in the global timers with this set up and I don't understand why. Specifically, if a register has a bit that's a '1' following a reset, I can't change that bit to a '0'. This is happening with the Global Timers Reference Registers (GTRFR1 - 4) and the Global Timers Prescale Registers (GTPSR1 - 4). The reset state of the GTRFRs is 0x and I can't change it to any other value. The reset state of the GTPSRs is 0x3 and I can't clear the 2 LSB. I can change any other bits in the prescale registers, but not the two which are a '1' at reset. There's a sequence that needs to be followed. You need to enable the timer first, then set the mode, then set the prescaler. I've attached some expect code for U-boot that generates a 1Hz output from timer 3 on an MCP8349. It's not quite what you have, but hopefully close enough for you to figure it out. I also have a simple char driver for Linux if you need it later on. COMMENT Set SICLR so that GPIO1_8 becomes TOUT3 send mm.w e114\r expect $mmPrompt send 8001\r expect $mmPrompt send q\r expect $mainPrompt COMMENT Enable timer 3 send mm.b e504\r expect $mmPrompt send 01\r expect $mmPrompt send q\r expect $mainPrompt COMMENT Set mode register send mm.w e520\r expect $mmPrompt send ff0c\r expect $mmPrompt send q\r COMMENT Set frequency to 1Hz send mm.w e524\r expect $mmPrompt send 1f77\r expect $mmPrompt send q\r expect $mainPrompt Hope this helps regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] jffs2 file system
--- Nethra [EMAIL PROTECTED] wrote: thanks ben, I have already tried to build jffs2 image as per link mentioned using mkfs.jffs2 utility, but mkfs.jffs2 is absent in host...so i downloded mkfs.jffs2 from net and used the same to create the image.Is it the correct way? Sounds reasonable. it is giveing error when booting... nethra OK, what's the error? Did you set the endianness correctly when using mkfs.jffs2? ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: CLI for embedded system
On Wed, 2007-02-21 at 17:18 +0530, pjmaiya wrote: Dear Ben, I have tried following option, with host as ppc_8xx, since we are using mpc860 processor and also we are using montavista provided compiler (ppc_8xx). Our embedded target runs on montavista linux with mpc860 processor and compiler given by monta vista(hard hat linux). host$ ./configure --host=ppc_8xx --build=i686 CC=ppc_8xx-gcc We are getting error ppc_8xx unkown host at some stage. When we further investigated clish code we found that we need to add our new architecture in aux_scripts/configure.sub file. We have successfully built that part. But for some libarary we are getting error in /usr/lib/libbstd++, but we need to change this path..only option left for us to change in configure file which requires autoconf tool..Also we need to change some thing in configure.in. We are little bit stuck in this part..Can U help in this regard.. Writing our make for clish is massive work!!! I really doubt you need to mess with any of these files. Have you tried the host parameter that I suggested (--host=ppc-linux-gnu)? I believe that worked for me, but it's been a while. Unfortunately I can't spare any time on this right now. Have you checked to see if there's a mailing list for the clish project? I imagine building this for a 32-bit PowerPC has been done before many times over. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: device tree / how to build/compile use with u-boot to boot uImage?
Tom, I feel your pain. On Fri, 2007-02-09 at 16:55 -0500, Morrison, Tom wrote: All, I've looked at the Documentation/powerpc/booting_without_of.txt, and this gives an explanation of the internal parts of the dts file, but it doesn't tell me how to practically pass it to the kernel from u-boot (e.g.: load to memory - and use bootm xxx yyy zzz) I am pretty darn confused about this whole thing. Can anybody point me to a SUCCINCT explanation of the use of a dts file (and how compile and use with u-boot to pass to kernel)? u-boot bootm kernel_address initrd_address dtb_address If you don't have an initrd, it's u-boot bootm kernel_address - dtb_address Hope that's succinct enough. Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: CLI for embedded system
Pjmaiya, On Thu, 2007-02-08 at 18:32 +0530, pjmaiya wrote: Hi, Can anybody give me link/built in package or source code for implmenting CLI for embedded system on linux. We have tried to implement our own CLI on linux(with bash shell as base), but it is massive work since we need to support Tab feature, history feature,help etc.. If you're looking for something to emulate Cisco's IOS shell, there's an open source project called 'clish': http://sourceforge.net/projects/clish/ I haven't really used this myself, so can't recommend for or against. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Target reset after linux reboot
On Thu, 2007-02-08 at 13:29 +0100, Frank Prepelica wrote: I got a problem. After rebooting linux system on the target, the target “hangs”. How could I get that the target makes a reset to start u-boot or linux again? You'll need to provide some details. With the information you've provided, I'd suggest cycling power. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC83xx: ns16550.c - 'SERIAL_PORT_DFNS' undeclared?
Russell, On Fri, 2007-01-19 at 11:28 -0800, Russell McGuire wrote: arch/ppc/boot/common/ns16550.c error: ‘SERIAL_PORT_DFNS’ undeclared here …… I don't think you should be building any code there... Are you using ARCH=powerpc (you should be) regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: MPC83xx: ns16550.c - 'SERIAL_PORT_DFNS' undeclared?
On Fri, 2007-01-19 at 12:14 -0800, Russell McGuire wrote: Ben, That could be the problem I am building using ARCH=ppc What is the difference between the two? I'm not by any means the expert, but I believe that ARCH=powerpc is a merge of 32 and 64 bit PowerPC architectures (plus all sorts of relatives like POWER and cell), and is where 'everybody' is moving. Many types of processors (including 83xx) have been fully transitioned to powerpc, while others are in the works. There are a few differences that you'd notice, especially the requirement for passing hardware information via device tree in ARCH=powerpc. I don't know if ARCH=ppc is going away for 83xx, but it isn't being maintained or updated, AFAIK. With ARCH=powerpc, you will hopefully be able to get your board booting soon, assuming your device tree is correct enough. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Using fixed_phy with gianfar
Thanks Vitaly! --- Vitaly Bordug [EMAIL PROTECTED] wrote: No, you do not miss - this is an issue. In fact MDIO bus was changed for numeric for gianfar-stuff, and has been remaining string for fs_enet. I think it makes sense to average this up, and will try to do that once will get 8349-mitx which is gianfar+ fixed user. The point is that fixed should be updated to numeric MDIO address encoding. This has to come through netdev, so I'll try to get it fixed by the next merge window. -- Sincerely, Vitaly Ideally (for me anyway), we'd be able to pass some fixed phy information via the device tree, for example speed and duplexity. This way a board could, for example, connect to one switch via RvMII @100FD and another via GMII @1000FD. Having parameters as numeric limits this capability, but presumably a simple encoding scheme could be make it work. I'm sure you've already thought of this, though... cheers, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Using fixed_phy with gianfar
Vitaly, Yes, I was thinking about something like 0:1001 or 0:101 where 1 at the end respects duplexity. Putting it into devtree is good but we'll need to unify the interface first. I'm sure you're working on lots of other things right now, so I'll go ahead and code something like this up and will pass it to you. You can then keep/modify/discard as you like. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
External interrupts in 2.6.19
Hello, I'm porting my board from 2.6.17 to 2.6.19 kernel, and now external interrupts aren't working any more. I'm using ARCH=powerpc on an MPC8349-based custom board. With the old code, we called ipic_init() from board init code with a table of IRQ senses. In the newer kernel, ipic_init() takes only an OF node as a parameter. Looking at the PIC registers, the external IRQs are all being set to level-triggered, when they used to be edge-triggered. I guess I haven't been following all of the discussions on changes to the IPIC code, and my little brain can't figure out the right way to do this. Can somebody please give a quick dump of how the new methodology is supposed to work? thanks, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Using fixed_phy with gianfar
Hello, My custom board has a couple of Ethernet switches attached via RvMII to the 'Gianfar' controllers of an MPC8349 CPU. We're using SPI instead of MDIO for control of the switches, and it looked like the 'fixed.c' PHY driver was the right thing to use. BTW, I'm using a 2.6.19 kernel. When I 'ifconfig up' one of the interfaces, the Gianfar driver tries to find a device on the MDIO bus of the variety bus_id:phy_id, where both bus_id and phy_id are numeric (defined in fsl_devices.h). The Fixed PHY driver creates devices on the MDIO bus with a bus_id that is a string, for example [EMAIL PROTECTED]:1. Obviously, these will never match up. The very crude hack I made to get things working was to modify the Gianfar driver to match the fixed string. I'm sure I'm missing something, and am wondering what the correct way to do this is. Should I have board-specific code that creates PHY devices conforming to the Gianfar expectations instead of calling 'fixed_mdio_register_device()', or something else? thanks, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Best location for call to spi_register_board_info () on PPC (MPC5200)
Henk,
On Wed, 2006-12-13 at 21:59 +0100, Henk Stegeman wrote:
I'm working on an SPI procol driver on the MPC52XX.
I spend some time in trying to find the best location for calling
spi_register_board_info () (which basically registers the relations
between protocol drivers and the SPI chip selects).
I wish to call this function from my copy of the
arch/ppc/platforms/Lite5200.c file since these relations are
board-specific, however I found that placing the call in any of these
functions (eg. lite5200_setup_arch) results in an -ENOMEM from the
spi_register_board_info () call.
Now I'm calling spi_register_board_info () from the spi controller
driver which is soo ugly.
Thanks in advance,
Here's how I do it, in my board-specific /arch/powerpc/platforms/83xx
file. Somebody please comment if I'm doing it wrong:
struct spi_board_info qsPrism_spi_devices[2] =
{
{
.modalias = SPI_SWITCH,
.bus_num = 0,
.chip_select = 0,
.max_speed_hz = 200,
},
{
.modalias = SPI_SWITCH,
.bus_num = 0,
.chip_select = 1,
.max_speed_hz = 200,
},
};
static int __init qsPrism_spi_board_init(void)
{
return spi_register_board_info(qsPrism_spi_devices, 2);
}
arch_initcall(qsPrism_spi_board_init);
*
SPI_SWITCH is my protocol driver. The 'arch_initcall' adds this to a
list of functions that gets called at init time. There is a hierarchy
of these registrations that you can research, but 'arch' is somewhere in
the middle, IIRC, and is a point where memory should be available.
regards,
Ben
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Compact Flash help
Hi Bala, On Thu, 2006-11-30 at 14:58 +0530, s.balamurugan wrote: Hello all, This is bala, I am using MPC8360 board and compact flash is connected via Local Bus Controller(UPM). I have the following questions what are the necessary document to be read for writting the driver for compact flash. What is the relation between compact flash and PCMCIA and PC Card. What are the CIS structure members. What are the documents to be read to understand the full concept of Compact Flash. If you're REALLY interested in knowing everything about Compact Flash, go here: http://www.compactflash.org/ You can download the spec, which should help you sleep. If you want to know how to interface Compact Flash to your Local Bus, here's a good document. I'm not intimately familiar with the 8360, but unless Freescale has changed their LBC design, it should apply: http://www.toshiba.com/taec/components/ApplNote/TSB_CF-Motorola_PPC8260_030325.pdf You shouldn't have to write your own driver for this. I don't feel totally comfortable giving you somebody else's code that isn't necessarily finished, but since you could Google it yourself anyway, here's a link to one that was put up for comment several months ago. I had no part in authoring it and have no idea where it stands regarding inclusion in the kernel, so please treat it as experimental. It will require a bit of work on your part to understand how to specify platform devices. http://lkml.org/lkml/2006/2/1/47 regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Compact Flash - lost interrupt
On Wed, 2006-11-29 at 19:10 -0800, Muruga Ganapathy wrote: The error message might be due to the wrong/improper configuration of interrupt and its attributes like whether it is level/edge sensitive. G.Muruganandam Thanks Ganapathy. Turns out it was a hardware problem. In True IDE mode the CF interrupt signal is active high, which explains why sometimes the interrupt was detected (albeit not at the right time). We missed that in the Toshiba document, and unfortunately it doesn't look like the polarity of IRQ lines is configurable on this CPU. Alas, another white wire. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Compact Flash - lost interrupt
Hello, I'm bringing up the Compact Flash interface on a custom board and am almost there, but not quite. I've seen many messages in the past about the 'lost interrupt' message, but I couldn't find anything corresponding closely to my situation. Can anyone shed some light? Here's a snippet of Linux booting: *** ## Booting image at 0020 ... Image Name: Linux-2.6.17 Created: 2006-11-29 19:38:51 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1103335 Bytes = 1.1 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Using MPC834x SYS machine description snip Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx hda: TOSHIBA THNCF512MDG, ATA DISK drive ide0 at 0xd1064000-0xd1064007,0xd106600d on irq 20 hda: max request size: 128KiB hda: 1000944 sectors (512 MB) w/2KiB Cache, CHS=993/16/63 hda:4hda: lost interrupt hda: lost interrupt hda: lost interrupt hda: lost interrupt hda: lost interrupt hda1 snip prism login: *** As you can see, the device is found and eventually the IDE driver assigns it ID hda1, but something's amiss. When I try to partition the drive I get the same thing: ~ # fdisk /dev/hda hda: lost interrupt hda: lost interrupt Command (m for help): p Disk /dev/hda: 512 MB, 512483328 bytes 16 heads, 63 sectors/track, 993 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device BootStart EndBlocks Id System /dev/hda1 * 1 992 499936+ 6 FAT16 The Compact Flash is configured in 'True IDE' mode on the local bus of a 400MHz MPC8349 processor. I've set the UPM timing according to the Toshiba app note that's floating around, and the interrupt is tied to IRQ4 (Interrupt #20). The fact that the driver probe can read information about the drive tells me that the memory bus is at least marginally functional. Interrupts are firing: ~ # cat /proc/interrupts CPU0 9:127 IPIC Level serial 14: 0 IPIC Level i2c-mpc 15: 0 IPIC Level i2c-mpc 16: 0 IPIC Level mpc83xx_spi 20: 12 IPIC Edge ide0 21:547 IPIC Edge eth2 BAD: 0 I'm using a driver supplied by Kumar Gala called 'cfide.c'. I've tried a couple of quite different CF cards, with the same result on both. Here's a portion of the kernel .config file: # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDECD is not set # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_IDE_ARM is not set CONFIG_BLK_DEV_CFIDE=y # CONFIG_BLK_DEV_IDEDMA is not set # CONFIG_IDEDMA_AUTO is not set # CONFIG_BLK_DEV_HD is not set thanks, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: A question about power on
On Thu, 2006-09-21 at 19:11 +0800, enorm wrote: After power on, cpu reads instruction from certain addr. But how does it know how many bits he can read at once. This can't be generalized. Read the Reset, Clocking and Initialization, or equivalent, chapter of your CPU's reference manual. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
How to find I2C address?
On Tue, 2006-09-12 at 10:13 -0400, Sachin Rane wrote: Hi, I am using AMCC PPC440GX evaluation board. I want to access serial EEPROM (AP31_U29) present on the board. I couldn't find the I2C address for this chip in the board manuals. Could you tell me where I can find it? These things typically have 1 to 3 address pins that are pulled up or down on the board, with a base address of 0x50. In other words, it's probably between 0x50 and 0x57. To be sure, download the datasheet from the chip vendor, and look on your board's schematics to see how the address pins are tied. There are various ways of probing the bus to get the info indirectly, but you should really be familiar with your hardware first. regards, Ben
Re: Stupid Telnet Question
Tim, --- Martin, Tim [EMAIL PROTECTED] wrote: snip When I just telnet locally from the serial console to the board (using the loopback IP 127.0.0.1) the telnet daemon connects, but the login program doesn't give me a chance to type a username or login. Question: What stupid thing have I done to cause this and how can I fix it? - This is what my console session looks like: # telnet 127.0.0.1 Entering character mode Escape character is '^]'. Linux 2.6.14 (172.16.5.11) (17:13 on Tuesday, 22 November 2011) Login incorrect Login incorrect Login incorrect Login incorrect Connection closed by foreign host. - And here's what syslog is saying: Nov 22 17:15:08 172 authpriv.info xinetd[1025]: START: telnet pid=1037 from=172.16.1.199 Nov 22 17:15:08 172 authpriv.notice login: FAILED LOGIN 1 FROM 172.16.1.199 FOR (null), Authentication failure For security reasons, Telnet is typically set up so that you can't log in using 'root'. This is because the data channel isn't encrypted so passwords are easily compromised. If you don't have any other users set up, it will give the behaviour that you're seeing. It's been a while since I've done this, but I think you need to edit /etc/xinetd.d/telnet to allow root use. Or add a user. Or install SSH. cheers, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Stupid Telnet Question
Tim, --- Martin, Tim tim.martin at viasat.com wrote: snip When I just telnet locally from the serial console to the board (using the loopback IP 127.0.0.1) the telnet daemon connects, but the login program doesn't give me a chance to type a username or login. Question: What stupid thing have I done to cause this and how can I fix it? - This is what my console session looks like: # telnet 127.0.0.1 Entering character mode Escape character is '^]'. Linux 2.6.14 (172.16.5.11) (17:13 on Tuesday, 22 November 2011) Login incorrect Login incorrect Login incorrect Login incorrect Connection closed by foreign host. - And here's what syslog is saying: Nov 22 17:15:08 172 authpriv.info xinetd[1025]: START: telnet pid=1037 from=172.16.1.199 Nov 22 17:15:08 172 authpriv.notice login: FAILED LOGIN 1 FROM 172.16.1.199 FOR (null), Authentication failure For security reasons, Telnet is typically set up so that you can't log in using 'root'. This is because the data channel isn't encrypted so passwords are easily compromised. If you don't have any other users set up, it will give the behaviour that you're seeing. It's been a while since I've done this, but I think you need to edit /etc/xinetd.d/telnet to allow root use. Or add a user. Or install SSH. cheers, Ben
CompactFlash on PQII Pro
Thanks Kumar, As always, you're several steps ahead of me. On Wed, 2006-08-23 at 18:04 -0500, Kumar Gala wrote: I know I posted a patch for cf-ide.c to lkml some time ago, this was to do a CF in true ide mode using the 83xx localbus. http://marc.theaimsgroup.com/?l=linux-kernelm=113877891224982w=2 We did some UPM setup in u-boot to use two CS on Localbus for this. In our case, we only have one CS available but it's going to a CPLD that will decode and provide two CSs to the CF. This will work as long as the UPM setup is identical for the two chip selects. Should be... Off-topic to this list, but do you have the U-boot code that you can share? If not, no worries. thanks, Ben
Platform device style question
Hello, A 'newbie-to-platform-devices' question: In a patch that Kumar just sent for a compact flash device, the resource data (I/O addresses, IRQ # etc.) are retrieved from the platform system. I guess I can either modify the device tree in U-boot by adding additional nodes, or instantiate a platform device in Linux __init code based on static information. The former gives the advantage of having the bootloader pass the info to the OS. (Somebody please correct me if I'm off-base here!) Are device trees meant to only contain information about the CPU and tightly-coupled peripherals, or is it considered OK-form to also include board-level hardware info? I guess they can really hold anything, but I'm trying to figure out the original intent. regards, Ben
CompactFlash on PQII Pro
Kumar, On Thu, 2006-08-24 at 13:25 -0500, Kumar Gala wrote: The only code in u-boot was the UPM setup code, I'm happy to send that to you. If it's no trouble, that would be great. My HW guy is calculating the settings, but this stuff can be frustrating to debug. BTW - was the system bus speed for your CPU 33 or 66 MHz? We're targeting for a 400MHz 8349 which has a 33MHz system bus.
Platform device style question
Thanks Vitaly, On Thu, 2006-08-24 at 22:06 +0400, Vitaly Bordug wrote: I'd suggest to make a look at LDD concerning linux device model... Thanks. I'll read it again. My little brain absorbs this stuff very slowly. For platform device, there's no need to cope with u-boot at all. You'll prolly need to register the respective platform device from the board-specific code, with proper name and driver's board-specific platform info. You may have a look at arch/ppc/syslib/ppc_sys.c about static PD definitions usage. My particular platform (MPC8349) gets its hardware info (CPU, IMMBAR, PCI, I2C, SPI resources etc.) from an OF device tree that is generated alongside U-boot and I guess embedded in the uImage file. (I apologize if I'm getting my jargon mixed up here) The OF device tree idea seemed like a slick way to abstract away some HW settings from Linux. I was imagining writing board-side platform device registration that gets its settings from the device tree, allowing a bit of re-use between similar but not identical boards. I'd make sense to figure out the platform device bus before digging into device trees. It's slightly different stuff, for similar aim, but anyway... Actually you do not strictly need devtree to cope with your case afaiu. I definitely have much learning to do. Thanks very much for the pointers! regards, Ben
CompactFlash on PQII Pro
Hello, I have a custom board where we've hung a CompactFlash on the local bus of an MPC8349 processor, intending to use it in 'True IDE' mode. The closest thing I've found in the kernel tree is drivers/ide/ppc/ide-m8xx.c, although it's *very* possible I'm not looking in the right place. I believe my chip's local bus is similar to the 8xx, so making this driver work with my hardware doesn't seem like that big a deal. I fully expect to have to monkey with UPM timings among other things. On the other hand, this seems like something other people would have done, maybe with one of the other PQ families like 82xx or 85xx. Does anyone have a patch, suggestions or flames they can throw my way? cheers, Ben
Problems dynamically linking busybox with ppc libs.
Keith, On Wed, 2006-08-16 at 10:53 +0200, Keith Redfern wrote: I am trying to dynamically link busybox with the correct libraries but run into problems with directory paths and CC/LD flags. I am using the toolchain supplied with ELDK and my target board is ppc_8xx based. The busybox version that I am using is 1.1.3. snip Is this the correct place to make modifications? Has anyone already figured the changes required to get this to work with ELDK toolchain? Any insight would be useful. ...?Keith I have busybox 1.2 building under ELDK 4.0, and didn't mess at all with the Make system, and am building for a ppc_6xx- target. I realize this isn't quite your setup, but is pretty close. As long as you have the tools listed in your PATH (in my case /opt/tools/eldk4.0/usr/bin:/opt/tools/eldk4.0/bin), you should be able to build fine using 'make menuconfig'. Just go to 'Busybox Settings-Build Options' and select 'Do you want to build BusyBox with a Cross Compiler?', in your case entering 'ppc_8xx-' or whatever the prefix is for your CPU. regards, Ben
ELDK 3.1.1 support for x86_64 host architecture
On Fri, 2006-08-04 at 22:11 +0200, Wolfgang Denk wrote: Yes, SuSE has always found interesting ways to break compatibility. That's why I avoid it. IIRC, SuSE provides a special tool linux32 which has to be used to run 32-bit applications on a x86_64 system. Don't ask me why they need it. Other distros run the 32-bit applications just fine without such intricacy. I don't know about SUSE, but to get ELDK 4.0 running on my Debian x86_64 server I had to install a package called 'ia32_libs'. regards, Ben
problems with mounting JFFS2 using CFI for AM29LV160MT on ppc8245 k2.4.x
Arun, Please keep the mailing list CC'd on all correspondence. As you can see, I've been busy for the past week and am sure there are others listening that are more qualified to answer. Anyway... On Wed, 2006-07-26 at 17:33 +0530, Arun Kumar wrote: Hi Ben , I guess this is the last stage before bringing the flash up . I am able to partition and open the particular partition agere-ets1 in Vi editor .(without NFS) after enabling the MTD_CHAR and MTD_BLOCK support . When I ttry to save the file /text file I get an internal flash timeout error .I have programmed my uWriteTiemout to be 500 . I am sending a dump of the out put and the cfi_cmdset002.c as well as the .config file snapshots . Please take a look :-) It seems the code on bringup disables fast programming . Looks like you now have char-based reads working, so I expect your kernel is now properly configured. The AMD chip you're using has been around for a while, so it's unlikely a source-code problem. Have you tried mtd-utils? If not, I recommend installing them on the board. The source as well as RPMs are available on-line at a number of places. Google will help you here. regards, Ben
problems with mounting JFFS2 using CFI for AM29LV160MT on ppc8245 k2.4.x
Arun, Looks like there are still some things broken in your MTD partition definition. I highly recommend that when debugging this, you boot from an NFS mount. That way you can modify files off-line (ie. from your development host). I'll point out a few things, but you're going to have to surf the source code a bit: On Mon, 2006-07-24 at 13:54 +0530, Arun Kumar wrote: Hi Ben , Thanks for your reply .It was indeed very comrehensive .I am able to proceed further But still there is a bit problem . When I try to mknod physically viz mknod /dev/mtd0 . It says the node is readonly . Can you please point out the problem . I am attaching a dump of the console . Again, put your root FS on an NFS mount and this won't be an issue. You can work out the ramdisk details later. AMD_FLASH_INIT called *aks * physmap flash device: 80 at ff80 virtual address Number of erase regions : 4 Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard) Primary Algorithm Table at 0040 Alternative Vendor Command Set: (None) No Alternate Algorithm Table Vcc Minimum: 2.7 V Vcc Maximum: 3.6 V No Vpp line Typical byte/word write timeout: 128 ?s Maximum byte/word write timeout: 256 ?s Full buffer write not supported Typical block erase timeout: 1024 ms Maximum block erase timeout: 16384 ms Chip erase not supported Device size: 0x20 bytes (2 MiB) Flash Device Interface description: 0x0002 - supports x8 and x16 via BYTE# with asynchronous interface Max. bytes in buffer write: 0x1 Number of Erase Block Regions: 4 Erase Region #0: BlockSize 0x4000 bytes, 1 blocks Erase Region #1: BlockSize 0x2000 bytes, 2 blocks Erase Region #2: BlockSize 0x8000 bytes, 1 blocks Erase Region #3: BlockSize 0x1 bytes, 31 blocks Amd/Fujitsu Extended Query Table v1.3 at 0x0040 number of CFI chips: 4 in amdstd_setup 0: offset=0x0,size=0x1,blocks=1 1: offset=0x1,size=0x8000,blocks=2 2: offset=0x2,size=0x2,blocks=1 3: offset=0x4,size=0x4,blocks=31 4: offset=0x80,size=0x1,blocks=1 5: offset=0x81,size=0x8000,blocks=2 6: offset=0x82,size=0x2,blocks=1 7: offset=0x84,size=0x4,blocks=31 8: offset=0x100,size=0x1,blocks=1 9: offset=0x101,size=0x8000,blocks=2 10: offset=0x102,size=0x2,blocks=1 11: offset=0x104,size=0x4,blocks=31 12: offset=0x180,size=0x1,blocks=1 13: offset=0x181,size=0x8000,blocks=2 14: offset=0x182,size=0x2,blocks=1 15: offset=0x184,size=0x4,blocks=31 cfi_cmdset_0002: Disabling fast programming due to code brokenness. aks Enabling * Are you sure you have the correct chip family chosen in your CONFIG? The block sizes found by CFI are different than those mentioned in amdstd_setup... CFI shows your devices being 2MB in size, while the other shows (1*1 + 2*8000 + 1*2 + 31*4 = 0x80) 8MB per chip. Something is amiss here. I don't have a clue about the fast programming. 'grep -R' is your friend. in MTD Partitioning 5No RedBoot partition table detected in phys_mapped_flash Using physmap partition definition Creating 3 MTD partitions on phys_mapped_flash: 0x-0x0004 : agere-ets0 mtd: Giving out device 0 to agere-ets0 0x0004-0x0008 : agere-ets1 mtd: Giving out device 1 to agere-ets1 0x0008-0x0007fffe : agere-ets2 mtd: partition agere-ets2 doesn't end on an erase block -- force read-only There's definitely a problem here. First of all, 0x7fffe is 0x8. Note that the start and end addresses you specify for this must be on erase block boundaries. Clean up your partition table to reflect what you want. You didn't mention whether you're passing partition info by command line or in init code. Also, if you're not using Redboot, get rid of that CONFIG option. regards, Ben -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060724/36ad88f7/attachment.htm
problems with mounting JFFS2 using CFI for AM29LV160MT on ppc8245 k2.4.x
Hi Arun, On Fri, 2006-07-21 at 20:26 +0530, Arun Kumar wrote: Hi , Can anyone help me in this naive problem ? Then a naive answer is most fitting... Turns out that's my specialty. # # Memory Technology Devices (MTD) # CONFIG_MTD=y CONFIG_MTD_DEBUG=y CONFIG_MTD_DEBUG_VERBOSE=2 CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CONCAT=y CONFIG_MTD_REDBOOT_PARTS=y CONFIG_MTD_CMDLINE_PARTS=y Probably get rid of REDBOOT if you're not using that bootloader # # User Modules And Translation Layers # # CONFIG_MTD_CHAR is not set # CONFIG_MTD_BLOCK is not set # CONFIG_MTD_BLOCK_RO is not set # CONFIG_FTL is not set # CONFIG_NFTL is not set # CONFIG_INFTL is not set You need to enable MTD_CHAR to read/write and MTD_BLOCK to mount Can any happy soul let me know :-- 1)How to mount jffs2 on this flash and also to test mtd-read/write routines ? Start with the char drivers (/dev/mtd0 etc.). You'll need one for each partition you want to experiment with. How about creating the nodes manually? mknod /dev/mtd0 c 90 0 mknod /dev/mtd1 c 90 2 etc. (minor # increments in 2s) Add a block device for each partition: mknod /dev/mtdblock0 b 31 0 mknod /dev/mtdblock1 b 31 1 etc. Once you clean up #3 below, you should be able to read/write the char devices using commands like 'cat', or write a simple user-space app using open, read, write, etc if you'd rather look at the actual binary data. You can then experiment with mounting the JFFS2. I recommend booting to an NFS file system then mounting the JFFS2 with something like: mount -t jffs2 /dev/mtdblock5 /mnt/temp(Use the correct partition) 2) Is it ok not to see mtd0.. partions in /dev directory . Pretty sure you'll need these 3 ) Where do I register the mtd partitions to get them noticed here ?? Looks like your partitions are already being found, but are probably not set up right. I don't know if this is a static definition in your board init code or passed by command line from the bootloader, but it looks like the values don't line up with your device: * Using physmap partition definition Creating 3 MTD partitions on phys_mapped_flash: 0x-0x0004 : foo-ets0 mtd: Giving out device 0 to foo-ets0 0x0004-0x001e : foo-ets1 mtd: partition agere-ets1 doesn't end on an erase block -- force read-only mtd: Giving out device 1 to foo-ets1 0x001e-0x0020 : foo-ets2 mtd: partition foo-ets2 doesn't start on an erase block boundary -- force read-only * -- Hopefully this helps you proceed a little bit. regards, Ben
I2C with bus muxes
Hello, Has anyone implemented devices like the Philips PCA954x I2C bus muxes under the /sysfs device model? I have some optical transponders on my board that through the wisdom of some committee all have the same fixed I2C address. To get around this, we put them behind muxes, creating 'virtual' I2C busses. I imagine this could be modeled something like the USB hub model, but that's just a first stab. regards, Ben
I2C with bus muxes
Thanks Travis, On Thu, 2006-07-20 at 11:22 -0400, Travis B. Sawyer wrote: I have a driver for 2.4.x that works with our SFP/XFPs. We also have a bunch of other 'stuff' hanging off of muxes. I haven't given it a go on 2.6, but I have it compiled and it doesn't complain on startup. I'm happy to see anything. Due to time constraints, I may end up doing most of my devices stuff 2.4-style anyway, at least for now, since I have a much firmer grasp on the concepts... Not sure if I should send it here, as it won't be in patch form... Please pass your code along whenever it's convenient. Your call whether to the list or just to me. Cheers, Ben -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060720/ea6a1e5d/attachment.htm
I2C with bus muxes
Way cool! Thanks a lot. I'll try it out when my hardware comes in... regards, Ben On Thu, 2006-07-20 at 13:51 -0500, Kumar Gala wrote: On Jul 20, 2006, at 10:16 AM, Ben Warren wrote: Hello, Has anyone implemented devices like the Philips PCA954x I2C bus muxes under the /sysfs device model? I have some optical transponders on my board that through the wisdom of some committee all have the same fixed I2C address. To get around this, we put them behind muxes, creating 'virtual' I2C busses. I imagine this could be modeled something like the USB hub model, but that's just a first stab. I'm pretty sure I submitted a set of patches for this upstream. However there was some desire to hold off until some other changes. http://marc.theaimsgroup.com/?l=linux-kernelm=114376108231285w=2 http://marc.theaimsgroup.com/?t=11431621411r=1w=2 - kumar -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060720/9509df32/attachment.htm
Knowing kernel module load address (insmod hasn't -m)
cat /proc/modules If you want more detailed information about a module (locations of .text, .data, .bss etc), enable CONFIG_KALLSYMS in your kernel and you'll see lots of goodness in the /sys/module/YOUR MODULE/sections directory. Do yourself a favor and browse http://lwn.net/Articles/driver-porting/ where Jon Corbet has written a really good series of articles about modules and device drivers in the 2.6 kernel. cheers, Ben On Thu, 2006-07-13 at 22:38 +0200, Antonio Di Bacco wrote: Hi all, where can be read at which memory address a module was loaded. I use the bb insmod that doesn't provide -m option. Bye, Antonio. ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
JFFS2 FS is read-only (not what I want)
Mathieu, Thanks for responding! On Mon, 2006-07-03 at 12:42 +0200, Mathieu Deschamps wrote: Do you mean that you can't even created a void file on / as root ? Else can you then put for instance text in it ? My point is can or can't you first create a new fs node and then can you write to file your changes, that's two possible causes. # pwd / # touch newfile touch: newfile: No space left on device # Yes indeed what about drivers/mtd/maps/physmap.c ? your parts are mask_flags: MTD_WRITEB_WRITEABLE and not MTD_CAP_ROM, aren't they ? My chip is pretty standard NOR type Flash, and gets recognized by CFI as using command set 0001. It gets these flags: #define MTD_CAP_NORFLASH(MTD_CLEAR_BITS|MTD_ERASEABLE) *** # Memory Technology Devices (MTD) # CONFIG_MTD=y # CONFIG_MTD_DEBUG is not set # CONFIG_MTD_CONCAT is not set CONFIG_MTD_PARTITIONS=y # CONFIG_MTD_REDBOOT_PARTS is not set # CONFIG_MTD_CMDLINE_PARTS is not set [...] # CONFIG_JFFS_FS is not set CONFIG_JFFS2_FS=y Better avoid redundacy but this is not a clue, I guess make won't be fooled by this. Sorry, what's redundant here? I just used 'make menuconfig', and hopefully it notices incorrect options. IMHO, it's not a generation-time issue Good. I'll keep plugging away with my BDI thanks again, Ben -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060703/f79d96c7/attachment.htm
JFFS2 FS is read-only (not what I want)
Chetan, On Mon, 2006-07-03 at 10:18 -0400, Anantharaman Chetan-W16155 wrote: Did you check to see if your flash banks are unlocked? According to U-Boot, only the first four sectors are locked. My JFFS2 partition is in sectors 37-52 (1-based). I'll definitely look more deeply into this, though. thanks, Ben -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060703/e83f1de5/attachment.htm
JFFS2 FS is read-only (not what I want)
Mathieu, IMHO, it's not a generation-time issue This is starting to look to me like a generation-time issue. I built another JFFS2 partition out of a random directory on my workstation, and it's behaving properly: $mkfs.jffs2 -U -d util -b -e 0x2 -o /tftpboot/prism/myutil.img On the target, I booted from NFS and mounted both MTD images. The original one is in /dev/mtdblock4 and the new one is at /dev/mtdblock3: bash-3.00# pwd /tmp bash-3.00# mkdir mnt1 mnt2 bash-3.00# ll total 8 drwxr-xr-x 2 root root 4096 Jul 3 2006 mnt1 drwxr-xr-x 2 root root 4096 Jul 3 2006 mnt2 bash-3.00# mount -t jffs2 -o rw,nolock /dev/mtdblock3 mnt1 bash-3.00# mount -t jffs2 -o rw,nolock /dev/mtdblock4 mnt2 bash-3.00# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/nfs 72054096 13245480 55148432 20% / /dev/mtdblock32048 592 1456 29% /tmp/mnt1 /dev/mtdblock42048 2048 0 100% /tmp/mnt2 As you can see, the new image is working fine. Looks like I need to debug the root FS! Thanks to all people who helped me out here! cheers, Ben
JFFS2 FS is read-only (not what I want)
On Mon, 2006-07-03 at 15:38 -0400, Ben Warren wrote: This is starting to look to me like a generation-time issue. I built another JFFS2 partition out of a random directory on my workstation, and it's behaving properly: Sorry for filling people's inboxes, but it turns out the problem was between the chair and keyboard. My JFFS2 partition was slightly less than 2MB, which I guess decompresses to 2 MB, filling up the partition. I must have been in the wrong directory when issuing the 'du' command. On the plus side, I've learned quite a bit about MTD and JFFS2 going through this exercise! regards, Ben -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060703/dd75515c/attachment.htm
JFFS2 FS is read-only (not what I want)
Hello, When I boot from a JFFS2 file system on my eval board, the file system is effectively read-only, and I can't figure out why. I'm pretty sure the kernel's configured for R/W MTD block access. Any help is greatly appreciated. The hardware in use is: Freescale MPC8349EMDS eval board. 8MB Q-flash with 64 uniform 128k sectors Here are the symptoms: # du -s 265492 .-- only 265k of data # df Filesystem 1k-blocks Used Available Use% Mounted on /dev/mtdblock42048 2048 0 100% / # mount /dev/mtdblock4 on / type jffs2 (rw) /proc on /proc type proc (rw) Here's what the kernel spits out at boot-up: *** physmap flash device: 80 at fe00 phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank Command set type 1 Intel/Sharp Extended Query Table at 0x0031 Using buffer write method cfi_cmdset_0001: Erase suspend on write enabled cmdlinepart partition parsing not available RedBoot partition parsing not available Using physmap partition definition Creating 6 MTD partitions on phys_mapped_flash: 0x-0x0004 : u-boot 0x0004-0x0008 : env 0x0008-0x0028 : kernel -- kernel boots from here 0x0028-0x0048 : initrd -- no initrd, this is empty 0x0048-0x0068 : jffs2 -- 2MB partition 0x0068-0x0080 : user -- empty *** I created the MTD partitions in a u-boot image that was pulled from the GIT tree about a week ago, and my kernel is 2.6.17-based. I wrote some board init code that sets the MTD physical mappings. Here are the MTD and JFFS2 parts of my .config file: *** # Memory Technology Devices (MTD) # CONFIG_MTD=y # CONFIG_MTD_DEBUG is not set # CONFIG_MTD_CONCAT is not set CONFIG_MTD_PARTITIONS=y # CONFIG_MTD_REDBOOT_PARTS is not set # CONFIG_MTD_CMDLINE_PARTS is not set # # User Modules And Translation Layers # CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y # CONFIG_FTL is not set # CONFIG_NFTL is not set # CONFIG_INFTL is not set # CONFIG_RFD_FTL is not set # # RAM/ROM/Flash chip drivers # CONFIG_MTD_CFI=y # CONFIG_MTD_JEDECPROBE is not set CONFIG_MTD_GEN_PROBE=y # CONFIG_MTD_CFI_ADV_OPTIONS is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set CONFIG_MTD_CFI_INTELEXT=y # CONFIG_MTD_CFI_AMDSTD is not set CONFIG_MTD_CFI_STAA=y CONFIG_MTD_CFI_UTIL=y # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set # CONFIG_MTD_OBSOLETE_CHIPS is not set # # Mapping drivers for chip access # # CONFIG_MTD_COMPLEX_MAPPINGS is not set CONFIG_MTD_PHYSMAP=y CONFIG_MTD_PHYSMAP_START=0xFE00 CONFIG_MTD_PHYSMAP_LEN=0x80 CONFIG_MTD_PHYSMAP_BANKWIDTH=2 # CONFIG_MTD_PLATRAM is not set # CONFIG_JFFS_FS is not set CONFIG_JFFS2_FS=y CONFIG_JFFS2_FS_DEBUG=0 # CONFIG_JFFS2_FS_WRITEBUFFER is not set # CONFIG_JFFS2_SUMMARY is not set # CONFIG_JFFS2_COMPRESSION_OPTIONS is not set CONFIG_JFFS2_ZLIB=y CONFIG_JFFS2_RTIME=y # CONFIG_JFFS2_RUBIN is not set *** The file system is the SELF that is included with DENX's ELDK, and built as at: http://www.denx.de/wiki/view/DULG/RootFileSystemDesignAndBuilding I used the following command to create the file system image, that was then loaded at address 0xfe48 via U-boot: mkfs.jffs2 -U -d rootfs -D rootfs_device.tab -b -e 0x2 -o jffs2.img I modified the table to name my serial devices /dev/ttyS0 and /dev/ttyS1 thanks for the help. Sorry if this is too verbose or includes the wrong information. regards, Ben
BDI-2000 Config file for MPC8349 eval board
Hello, Does anybody have a solid config file for the Freescale MPC8349EMDS eval board? I guess the MPC8349ADS would be fine too, since I've been told they're the same thing. I've been tweaking the file named 'mcp8349e.cfg' that shipped with the BDI, but it's a bit flaky with my board. In particular, sometimes it can't write to the Flash programming workspace, maybe indicating that the DDR isn't properly set up, but there have been other things too that are slowly eating at me. thanks, Ben
GPIO endianness on MPC8349
Hello, I'm a noobie to this CPU, and am utterly confused with how the bits are ordered on the GPIO ports. I imagine it's the same as all Freescale PPCs, but who knows. Anyway... Using an MPC8349MDS eval board, I have one LED to play with. From the schematic, it's connected to GPIO1[1]. From other processors that I've worked with, I would have expected to toggle it with either 0x4000 (IBM 405) or 0x0002 (68360). Nope. To make this bit move, I mess with bit 0x0040 in the appropriate DAT register. This leads me to believe that either the bit ordering is something like ...89abcdef01234567 (sorry for the confusing notation, but hopefully it makes sense) or the schematic has a typo. Since I'm trying to write a generic GPIO handler, I'd like to have a little confidence in my extrapolation from a single point. Can anybody shed some light on this? thanks, Ben
GPIO endianness on MPC8349
Sorry for wasting bandwidth (again). Turns out my schematic is for an earlier spin of the board. regards, Ben On Mon, 2006-04-10 at 15:06 -0500, Kumar Gala wrote: On Apr 10, 2006, at 2:48 PM, Ben Warren wrote: Hello, I'm a noobie to this CPU, and am utterly confused with how the bits are ordered on the GPIO ports. I imagine it's the same as all Freescale PPCs, but who knows. Anyway... Using an MPC8349MDS eval board, I have one LED to play with. From the schematic, it's connected to GPIO1[1]. From other processors that I've worked with, I would have expected to toggle it with either 0x4000 (IBM 405) or 0x0002 (68360). Nope. To make this bit move, I mess with bit 0x0040 in the appropriate DAT register. This leads me to believe that either the bit ordering is something like ...89abcdef01234567 (sorry for the confusing notation, but hopefully it makes sense) or the schematic has a typo. Since I'm trying to write a generic GPIO handler, I'd like to have a little confidence in my extrapolation from a single point. Can anybody shed some light on this? This is because the Freescale docs are misleading. If you look at the schematic you will see the LED is wired to GPIO1[5] which makes sense for the 0x40 value you have to use. - kumar -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060410/0a3f1a73/attachment.htm
