EXT2-f error Some more info
Hi Philip I executed fsck on the ramdisk.image and it says clean. For second possibility , I didn't get any error there [ I gv some printk and checked]. The third step I am trying to find out. Before that I thought I will tell about the custom board memory map. There is no much difference between the 440GP evaluation kit except the boot rom setting. Local memory/peripherals DDR-SDRAM 0x0 0x0 0BFF 64MB SRAM0x0 8000 0x0 8000 1FFF 8KB Internal peripherals EBCO memory banks BOOT ROM (CS0)0x1 FFFE 0x1 128KB FPGA (CS1) 0x1 FFE0 0x1 FFEF 1MB FPGA (CS2) 0x1 FFD0 0x1 FFDF 1MB UART0 Registers 0x1 4 0200 0x1 4000 02078B IIC0 Registers 0x1 4 0400 0x1 4000 041F 32B PCI registers0x2 0EC0 0x2 0EC8 01F8 504B. One question regarding the booting. loaded at: 0100 0134A1BC zimage at: 01005970 010829D3 initrd at: 01083000 013465FE avail ram: 0040 0080 Above console output says that avail ram is from 4MB to 8MB. What this means whether only 4MB is available. I am asking this question since I have a ramdisk about 8MB[Without compression]. Will this cause a problem? Thanking you in advance Regards Aman - Original Message - From: <[EMAIL PROTECTED]> To: "Aman" Cc: "linuxppc embedded" ; Sent: Tuesday, November 05, 2002 9:02 PM Subject: Re: EXT2-f error > > >Hi All > > > >I have built a zImage.initrd.ebony image [ Kernel + Ramdisk] for my custom > >board which has 440GP as its processor. This board doesn't have ethernet > >support. However the kernel image contain network and ethernet support. > > > > > >If I download this image to the custom board , I get the following errors. > >"EXT2-fs error (device ramdisk(1,0)): ext2_check_page: bad entry in > >directory #20: unaligned directory entry - offset=0, inode=4294967295, > >rec_len=65535, name_len=255". > > > >I tried the same image with my evaluation board , it works fine. I have > >taken the ramdisk image from HHL. Can you help me in solving this issue. > > Well you've obviously got a corrupted fs, what you have to do is find out > where it is being corrupted. There are 3 possibilities: > > 1. The initrd file (initrd.gz?) is corrupt itself. This is probably > unlikely because you say your evaluation board works fine. However, the > supplied kernel output suggests the initrd file is not clean. You should do > an > fsck on the initrd file. This can be done by ungzipping the initrd file > and attaching to a loopback device, .i.e. > > losetup /dev/loop0 initrd > fsck -t ext2 /dev/loop0 > losetup -d /dev/loop0 > > 2. If that's okay, the initrd image may be being corrupted when loaded into > memory by the bootloader, and before it has been de-compressed by the > ramdisk code (drivers/block/rd.c::crd_load). Gunzip should return an error > if that's the case, as it will not be able to decompress the entire > ramdisk. Your error may be explained because you're ending up with a > truncated decompressed filesystem in the ramdisk. > > 3. If that's okay, the only other possibility is something is overwriting > your buffer cache (where your ramdisk is sitting). > > Both 2 & 3 could be quite tricky to track down. What is the differences > between the custom and evaluation board, that may give some pointers. > > Phillip > > > > > > "Aman" >To: "linuxppc embedded" > Sent by: cc: > owner-linuxppc-embedded at lists.lSubject: EXT2-f error > inuxppc.org > > > 05-Nov-2002 01:41 PM > > > > > > > > Hi All > > I have built a zImage.initrd.ebony image [ Kernel + Ramdisk] for my custom > board which has 440GP as its processor. This board doesn't have ethernet > support. However the kernel image contain network and ethernet support. > > If I download this image to the custom board , I get the following errors. > "EXT2-fs error (device ramdisk(1,0)): ext2_check_page: bad entry in > directory #20: unaligned directory entry - offset=0, inode=4294967295, > rec_len=65535, name_len=255". > > I tried the same image with my evaluation board , it works fine. I have > taken the ramdisk image from HHL. Can you help me in solving this issue. > > Thanking you in advance > Regards > Aman > > > > Below is the console output of my custom board > > loaded at: 0100 0134A1BC > zimage at: 01005970 010829D3 > initrd at: 01083000 013465FE > avail ram: 0040 0080 > > Linux/PPC load: root=/dev/ram0 ramdisk_size=8192 > Uncompressing Linux...done. > Now booting the kernel > Linux version 2.4.17_mvl21-ebony (root at hardhat) (gcc version 2.95.3 > 20010315
ELDK 2.0 released
In message you wrote: > > wd is probably Wolfgang Denk's login name. Therefore it won't matter. You are right in the first part, but it _does_ matter, as it points out a gap in our quality insurance which was not detected before the final release :-( Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de See us @ electronica 2002 in Munich, Nov 12-15, Hall A3, Booth A3.325 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ELDK 2.0 released
In message <001d01c28579$7216d070$cc00a8c0 at ycigrnd.ycig.com> you wrote: > I use the follwoing command line to install > without root account > ./install -d /eldk2.0.2 ppc_8xx > > warning:user wd does not exist, using root > . Yes, I'm sorry, but I mistakenly ran the final build under my own id, which was not noticed here because I have an account on all machines... > and it ends up successfully. > > Does it affect works? No, it has absolutely no consequences. The tools will work fine anyway. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de See us @ electronica 2002 in Munich, Nov 12-15, Hall A3, Booth A3.325 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
problems ..to boot linux 2.4.4 on fads mpc860 please help!!!!!!!!
Hi there! I hope this helps... First of all, a coleague managed to make a 850FADS board work properly, so the credit is his. We're using PPCBoot 1.2 and kernel-2.4.20pre1. The first thing is to make sure that the ppcboot environment variable "clocks_in_mhz" IS NOT DEFINED. It would NOT exist, not be defined as 0 or 1. It changes the clock dividers in the processor that is not good. This should make the kernel boot at least with a ramdisk. If you have trouble to make the ethernet interface work, as we did, you should edit the include/asm-ppc/commproc.h and arch/ppc/platforms/fads.h files. In the first file, you should add the following: /*** FADS / #ifdef CONFIG_FADS /* This ENET stuff is for the MPC850SAR with ethernet on SCC2. Some of * this may be unique to the FADS850SAR configuration. * Note TENA is on Port B. */ #define PA_ENET_RXD ((ushort)0x0004)/* PA 13 */ #define PA_ENET_TXD ((ushort)0x0008)/* PA 12 */ #define PA_ENET_RCLK((ushort)0x0200)/* PA 6 */ #define PA_ENET_TCLK((ushort)0x0800)/* PA 4 */ #define PB_ENET_TENA((uint)0x2000) /* PB 18 */ #define PC_ENET_CLSN((ushort)0x0040)/* PC 9 */ #define PC_ENET_RENA((ushort)0x0080)/* PC 8 */ #define SICR_ENET_MASK ((uint)0xff00) #define SICR_ENET_CLKRT ((uint)0x2f00) /* RCLK-CLK2, TCLK-CLK4 */ #endif /* CONFIG_FADS */ It should be put together with the other boards' definitions. The fads.h file shoud be edited in these definitions: < /*** defines taken from PPCBoot 1.2 ***/ < #define BCSR_ADDR ((uint) 0x0210) < #define BCSR_SIZE ((uint)(64 * 1024)) < #define BCSR0 ((uint) (BCSR_ADDR + 00)) < #define BCSR1 ((uint) (BCSR_ADDR + 0x04)) < #define BCSR2 ((uint) (BCSR_ADDR + 0x08)) < #define BCSR3 ((uint) (BCSR_ADDR + 0x0c)) < #define BCSR4 ((uint) (BCSR_ADDR + 0x10)) < /*** ***/ That should do the trick. Again, we are using a FADS850SAR board, which is not the same you have, but the spirit of the whole thing is to take the info from a working ppcboot to the kernel. Hope it helps. -- "All things are ready, if our minds be so" The Life Of King Henry V - William Sharespeare Leonardo Pereira Santos Engenheiro de Projetos PD3 Tecnologia av. Par? 330/202 (51) 3337 1237 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
serial reset?
Hi, I'm working on sleep on the 405LP. In one mode the chip is powered down and all state must be saved/restored by software. My current problem is with the UART (and I'm using serial console only, so it's problem). When I wake up, I can type commands to my shell and see them echoed correctly. However the result of those commands is garbled, like so: ls 1 tm[lc ;u;v 43m Sometimes I get the message "ttyS: 1 input overrun(s)". Return characters come through as spaces. I've tried to save/restore the UART registers just like all the others. Unfortunately FCR is write-only, and my attempts have just resulted in no serial activity at all. I've also tried the unregister_serial/register_serial calls to the serial driver (intended for PCMCIA). I can't see how those ever worked -- unregister_serial doesn't reset state->count, which causes register_serial to complain the device is already open. When I hack the driver though, I get the same result though: dead serial. This is a 2.4.17 kernel. Can you think of anything situation that would allow correct character echo but not output? I don't mind going through a full serial initialization if necessary, but it doesn't look like the driver was mutated *ahem* written with this in mind... -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Using intrd with 2.4.20-pre2
I'm getting stuck when mounting the initrd. This using the ppc 2.4 galileo tree at 2.4.20-pre2. I get as far as "VFS: Mounted root (rootfs filesystem)" On linuxppc_2.4.11_devel I would see "VFS: Mounted root (romfs filesystem) readonly" The romfs is found and uncompressed successfully. Is there a specific root=/dev/something I am supposed to pass (build) into the kernel cmdline? (no console/keybd) I've tried root=/dev/ram0, root=/dev/initrd and no root clause all with no success. I've uncompressed and mounted the file on a loopback device on my Mac, so it is not corrupted. It mounts as type romfs, not ext2, is that OK? Thanks, Gary Hannon ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Thruput slow unless select() on stdin frequently
The setup is an MPC860T, 50 MHz, Redhat linux 2.2.13. The QMC channels do not interrupt on transmit and receive. QMC is active on SCC2. The console use SMC1 for serial transmit and rec to an ASCII terminal. I have a thread which continuously loops, doing 2 things: (1) It executes a UDP recvfrom() for any of 12 UDP ports which may be active, and if a UDP pkt is recd, it queues it and the associated buffer descriptor in a circular Tx queue for subsequent transmit out 1 of 12 QMC channels to an external device. (2) It then checks the circular QMC Rx buffer descriptor queue for any pkts recd from a QMC SCC2 channel, from an external device, and sends them out using UDP sendto(). I need to check periodically for a serial key input through the SMC1 serial port. I use select(stdin) to check for it. If I do this select() check in its own thread, then the QMC circular transmit queue grows and grows, and finally fills up (QMC not transmitting queued buff decs fast enough), and the above thread doesn't empty the circular rec queue fast enough. I think the thread scheduler is late switching to this thread, sometimes as long as 30ms or so. If I move the select(stdin) inside the same continuously looping thread mentioned above, executing it, say, every 20th execution of the loop, then this speed things up. If I increase this number for select(stdin) execution to 50, then the xmt and rec circular queues start growing. The longer duration between select() execution, the faster the queues fill up. If the select is not executed at all, the queues fill up extremely fast and the system is bogged down. It's as though the stdin must be tested very frequently, even though no serial keys are there to be getc()'d, or some part of the code blocks. If I call select() too frquently, then that of course bogs things down, also. I checked into the kernel, and if it appears that do_select(), in fs/select.c, must be called from within sys_select(). The select(stdin) that works is: FD_ZERO(&read_file_descr); FD_SET(fileno(stdin),&read_file_descr); timeout_kbHit.tv_sec = 0; timeout_kbHit.tv_usec = 1; select(1,&read_file_descr,NULL,NULL,(struct timeval*) &timeout_kbHit); Thanks, Steven Vacca Valcom, Inc. Roanoke, Virginia -Original Message- From: Georg Klug [SMTP:gklug at giga-stream.de] Sent: Tuesday, November 05, 2002 4:01 AM To: svacca at valcom.com Cc: Ppc Embedded Subject:RE: Thruput slow unless select() on stdin frequently Hi Steven, unfortunately, I don't know your board, but from the effect you are seeing, I would say it is some sort of an interrupt problem. Do you have shared IRQs? Was the interrupt service routine of the "QMC channel" driver correctly installed? Does the interrupt really occur? Those would be the things I would be searching next. Kind regards, Georg Klug > --- stdin appears to block until a select() tests it, thus slowing >system code execution way down. --- > > My MPC860T app executes UDP recvfrom()'s and sendto()'s > at regular intervals. The recvfrom() UDP pkt data is queued with > a buffer descriptor for transmission on a QMC channel to an > external device. The data read from the device on a QMC > channel is queued with a buffer descriptor for subsequent sendto(). > > But if I do not constantly execute a select() (timeout = 10us) > on stdin (serial keyboard - not being used often) at a fast enough > rate (i.e. if the select() is executed in it's own thread and doesn't > get scheduled frequently enough) the code execution slows way > down, and I find that the queued QMC channel data, residing > in the circular queues doesn't get transmitted fast enough > and the queues grow and grow. Doing no select() on stdin > basically shuts the QMC buff desc processing down. > > It's as though, even with no serial chars coming in, stdin > blocks until the select() tests it. I need to avoid this blocking, yet > still periodically check for a serial key input on stdin. > > Any ideas out there in Linux Embedded-land? > > Thanks, > > Steven > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
