Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
beattie wrote:
Unless somebody can figure out how to enable the JTAG there is not going to be a new u-boot.
i was just wondering if you could explain why.
what does JTAG provide that the serial connector doesn't?
(i'm trying to get familiar with how the system works so i'll feel more comfortable looking into using a custom firmware with everyone)
Thanks,
Offline
http://en.wikipedia.org/wiki/JTAG
So lets put this like that: if you fail flashing or if you flash invalid/not correctly working u-boot then you will not have any serial output and also no operating system will be loaded until you correctly flash properly working u-boot using jtag.
Offline
i went poking around online at the MPC8421 specs.
http://www.freescale.com/files/32bit/do … pdf?fpsp=1
on page 47, there's a COP pinout, 16 pins, which show access to a possible JTAG interface.
I looked at the screenshot on the wiki, and there seems to be a 16 pin connector labled J8, near the battery.
since i'm a software guy with very little hardware experience, i'm not brave enough, nor knowledgeable enough to see if this J8 is the COP pinout that exists for the MPC8241, so i wanted to ask you, if you had looked at J8 as a viable JTAG interface already?
Offline
beattie,
I'm assuming that you did not have any luck with the following minimal config on the jtag port:
http://nas-central.org/index.php/Add_Jtag_Port
1 - TDO
3 - TDI
6 - Vcc (i have 3.3 vdc on my board with power on)
7 - TCK
9 - TMS
16 - GND
It appears, at least on my board, that those pins have components populated on their traces.
I have a jtag adapter coming (prolly wiggler/clone?) from ebay for $15 - even if this proves futile on dlink hardware, i've got a pile of bricked routers, etc that I need to dive into..
EDIT:
ok, nevermind - i see that you already have this diagram on your site.. you have probably pulled out your hair already trying to get some response out of this box....
Last edited by jens (2007-12-20 21:25:03)
Offline
well, it looks like i may have suceeded in jtag access through some board modification
looks like dlink left out the AND gates between dlinks on board reset and the jtag/cop tRST
(see pg 46 of MPC8241 Integrated Processor Hardware Specifications, Rev. 9 PDF, figure 27 "COP Connector Diagram")
I think the sm5964a controller is hardwired to keep hRST and TRST high (And pull low for a reset/poweron). I removed the shunt (0 ohm) resistors at R28, added a pull up resistor of 10k at R166 and placed a jumper across the missing AND gate at Q7
(PLEASE DONT TRY THIS AT HOME YET AS I STILL HAVE TO DO SOME MORE TESTING TO SEE WHAT EXACTLY IS NECESSARY)
I also did some extra jumpering across the hRST gate (Q6) -- but i dont think this is necessary
[root@crash ~]# jtag UrJTAG 0.7 #886 Copyright (C) 2002, 2003 ETC s.r.o. Copyright (C) 2007, 2008 Kolja Waschk and the respective authors UrJTAG is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for UrJTAG. WARNING: UrJTAG may damage your hardware! Type "quit" to exit, "help" for help. jtag> cable wiggler parallel 0x378 Initializing parallel port at 0x378 jtag> detect IR length: 8 Chain length: 1 Device Id: 0 (0x0000000000000000) chain.c(114) Part 0 without active instruction chain.c(145) Part 0 without active instruction chain.c(114) Part 0 without active instruction jtag> include motorola/mpc8241/1.2 jtag> endian big jtag> instruction SAMPLE/PRELOAD jtag> shift ir jtag> shift dr jtag> dr 000110110000110001010001000011101100001011000100110100000000000000000001000000000000001010000001000000001111010101110000000000000000000000000000000010000000000000000000000000000000000001111001100010100011110000011101111111111110000000100000001111001111000100100000100000011111101110111011111111110101101111010001011011000101100000001001011111110101010010110100000010001010110110001000101010011101000000000000000000000000000000000000000000000100011111010100111110001110011001111101111110000000000000000000000 jtag> instruction EXTEST jtag> shift ir jtag> initbus mpc824x jtag> detectflash 0xFFc00000 Query identification string: Primary Algorithm Command Set and Control Interface ID Code: 0x0002 (AMD/Fujitsu Standard Command Set) Alternate Algorithm Command Set and Control Interface ID Code: 0x0000 (null) Query system interface information: Vcc Logic Supply Minimum Write/Erase or Write voltage: 2700 mV Vcc Logic Supply Maximum Write/Erase or Write voltage: 3600 mV Vpp [Programming] Supply Minimum Write/Erase voltage: 0 mV Vpp [Programming] Supply Maximum Write/Erase voltage: 0 mV Typical timeout per single byte/word program: 128 us Typical timeout for maximum-size multi-byte program: 128 us Typical timeout per individual block erase: 1024 ms Typical timeout for full chip erase: 0 ms Maximum timeout for byte/word program: 256 us Maximum timeout for multi-byte program: 4096 us Maximum timeout per individual block erase: 16384 ms Maximum timeout for chip erase: 0 ms Device geometry definition: Device Size: 4194304 B (4096 KiB, 4 MiB) Flash Device Interface Code description: 0x0002 (x8/x16) Maximum number of bytes in multi-byte program: 32 Number of Erase Block Regions within device: 2 Erase Block Region Information: Region 0: Erase Block Size: 8192 B (8 KiB) Number of Erase Blocks: 8 Region 1: Erase Block Size: 65536 B (64 KiB) Number of Erase Blocks: 63 jtag>
some things don't look right above,
not sure exactly where i should be looking for detectflash -- any ideas?
im really a newbie at jtag'ing
I will have to do some more work and then eventually document it on the wiki
this looks promising though!!!
this is working without TRST pin
Last edited by jens (2008-01-01 01:25:31)
Offline
Wow, this is exciting news! Thanks for sharing your findings.
Offline
Right now I only have:
removed R28 bridge (was connecting pin 11 of sm5964a to nTRST ?)
add 10k ohm resistor at R166
added jumper across Q7 gate (from lead connected to pin 4 of J8 jumpering across to lead of Q7 on same trace as pad of R165)
This seems to hold nTRST high, - now all I need connected on my JTAG adapter is:
1 - TDO
3 - TDI
6 - Vcc (3.3vdc)
7 - TCK
9 - TMS
16 - GND
This is working. I can do "readmem 0xfff00000 100 testrom.bin" then do "od -xa testrom.bin" and see U-Boot 0.2.0 header.
Unfortunately, it seems that flash writing is not yet supported with urjtag 0.7, possibly due to the Spansion flash chips not being identified. Some code/hacking needs to be done to adapt this (maybe?)
Any ideas folks?
jtag> flashmem 0xfff00000 u-boot.bin Chip: AMD Flash Manufacturer: AMD Chip: Unknown (ID 0x007e) Protected: 0000 program: flash_unlock_block 0xFFF00000 IGNORE block 0 unlocked flash_erase_block 0xFFF00000 ............................................flash_erase_block 0xFFF00000 DONE erasing block 0: 0 flash_unlock_block 0xFFF02000 IGNORE block 1 unlocked flash_erase_block 0xFFF02000 ...........................................flash_erase_block 0xFFF02000 DONE erasing block 1: 0 flash_unlock_block 0xFFF04000 IGNORE block 2 unlocked flash_erase_block 0xFFF04000 ............................................flash_erase_block 0xFFF04000 DONE erasing block 2: 0 flash_unlock_block 0xFFF06000 IGNORE block 3 unlocked flash_erase_block 0xFFF06000 ...........................................flash_erase_block 0xFFF06000 DONE erasing block 3: 0 flash_unlock_block 0xFFF08000 IGNORE block 4 unlocked flash_erase_block 0xFFF08000 ............................................flash_erase_block 0xFFF08000 DONE erasing block 4: 0 flash_unlock_block 0xFFF0A000 IGNORE block 5 unlocked flash_erase_block 0xFFF0A000 ............................................flash_erase_block 0xFFF0A000 DONE erasing block 5: 0 flash_unlock_block 0xFFF0C000 IGNORE block 6 unlocked flash_erase_block 0xFFF0C000 ............................................flash_erase_block 0xFFF0C000 DONE erasing block 6: 0 flash_unlock_block 0xFFF0E000 IGNORE block 7 unlocked flash_erase_block 0xFFF0E000 ...........................................flash_erase_block 0xFFF0E000 DONE erasing block 7: 0 flash_unlock_block 0xFFF10000 IGNORE block 8 unlocked flash_erase_block 0xFFF10000 .......................................flash_erase_block 0xFFF10000 DONE erasing block 8: 0 addr: 0xFFF1B800 verify: verify error: readed: 0x000000FF expected: 0x00000027
Last edited by jens (2008-01-02 23:54:37)
Offline
Maybe beatie can take a look and see what's going on?
Offline
I was initially having trouble, so
placed parallel port on EPP (not ECP!) &
altered pinout mapping in urjtag-0.7/src/tap/cable/wiggler.c to match my Kuzito (wiggler-style) clone adapter
a few pieces of info that might be helpful:
seems there is a device file available for xjtag that might have useful info:
http://www.xjtag.com/examples/Memory/Fl … xM.xje.php
of course there is the datasheet (with some cfi info?):
http://www.spansion.com/products/S29GL032M.html
edit:
looks like we have S29GL032M90TAIR4
which means: R4 = x8/x16, VCC=3.0-3.6V, Bottom boot sector device, bottom two
address sectors protected when WP#/ACC=VIL
Last edited by jens (2008-01-03 21:32:34)
Offline
Here is a diagram (attached) of how I have my unit modded. I'm not entirely sure if it's completely necessary.. Maybe after JTAG halts cpu, watchdog (sm5964a controller) pulls TRST and HRST low to reboot unit?
Either way, I can still "do_reboot" and with this mod, and power button appears to be working normally.
Anybody else care to try JTAG'ing without mod (and without trst pin)
Note: if the watchdog is the problem, try JTAG'ing directly after a fresh powerup, before kernel has a chance to boot up watchdog?
Any thoughts from some pro hackers?
Last edited by jens (2008-01-07 04:14:50)
Offline
Ok,
I actually have a successful flashmem going now.
Turns out urjtag-0.7 (even latest SVN) doesnt work on this.
There is a patched version of openwince jtag tools from kurobox/linkstation variety.
http://www.kurobox.com/downloads/JTAG/jtagdir.tar (it's actually a .tar.gz file)
need to build include folder (for openwince), then build jtag
I think both use ./autogen.sh
I needed to apply the mpc8241.diff (patch /usr/local/share/jtag/motorola/mpc8241/1.2 mpc8241.diff)
then use the commands in "lsjtag" script (modify for your cable)
I also had to modify the wiggler.c for my special wiggler-clone pinout
I can succesfully "flashmem 0xfff00000 u-boot.bin" and verify works, and I can also do readmem for the first few bytes and see my new U-Boot 1.1.4 text header---
However, after a power cycle, u-boot not working (no console output ?)
So now it seems I have to figure out how to build a working u-boot...
I wish dpavlin could help here.. Seems he had a partially working ram build of u-boot going.
Last edited by jens (2008-01-08 10:41:23)
Offline
jens,
Good work. Looks like you're on the right track. Once I have some time off I would like to get mine going as well. Thanks a bunch for the writeup. Excellent finding.
Offline
Got it booting with dpavlins mods to the linkstation 2.1.0 patch to u-boot 1.1.4. I think I had inadvertantly swapped the console ports in Sandpoint8245.h
It's a start, but lots of work to be done!
U-Boot 1.1.4 LiSt 2.1.0 (Jan 8 2008 - 15:35:29) CPU: MPC8245 Revision 1.2 at 170.503 MHz: 16 kB I-Cache 16 kB D-Cache Board: Sandpoint 8245 Unity ##Test not implemented yet## DRAM: 32 MB FLASH: *** failed *** ### ERROR ### Please RESET the board ###
working on porting the dlink uboot 0.2.0 amd-flash.c changes over to 1.1.4 flash.c
I'm not really C hacker - so I will need some help here...
Last edited by jens (2008-01-09 08:40:01)
Offline
a little bit further...
U-Boot 1.1.4 LiSt 2.1.0 (Jan 9 2008 - 00:33:33) CPU: MPC8245 Revision 1.2 at 170.503 MHz: 16 kB I-Cache 16 kB D-Cache Board: Sandpoint 8245 Unity ##Test not implemented yet## DRAM: 32 MB FLASH: FUJI_DL323BE 4 MB Using default environment In: serial Out: serial Err: serial => ? ? - alias for 'help' base - print or set address offset bdinfo - print Board Info structure bootm - boot application image from memory cmp - memory compare coninfo - print console devices and information cp - memory copy crc32 - checksum calculation echo - echo args to console erase - erase FLASH memory flinfo - print FLASH memory information go - start application at address 'addr' help - print online help loadb - load binary file over serial line (kermit mode) loads - load S-Record file over serial line loop - infinite loop on address range md - memory display mm - memory modify (auto-incrementing) mtest - simple RAM test mw - memory write (fill) nm - memory modify (constant address) pci - list and access PCI Configuration Space printenv- print environment variables protect - enable or disable FLASH write protection reset - Perform RESET of the CPU run - run commands in an environment variable setenv - set environment variables version - print monitor version =>
Offline
another nice thing... I can now upload, flash, and test new u-boot images at 57600 bps through u-boot (1 minute as opposed to 20-30 mins)-- jtag is too slow. Of course, if we do something to mess up U-boot to where it wont boot, back to jtag'ing.
setenv baudrate 57600 loadb 0x100000 protect off 0xfff00000 0xfff1ffff erase 0xfff00000 0xfff1ffff cp.b 100000 0xfff00000 ${filesize} protect on 0xfff00000 0xfff1ffff
after a manual reset, i have a new u-boot
When I get more time, I will try to make up some diffs of what I have so far against dpavlins u-boot git (http://git.rot13.org/)
U-Boot 1.1.4 LiSt 2.1.0 (Jan 9 2008 - 12:52:33) CPU: MPC8245 Revision 1.2 at 170.503 MHz: 16 kB I-Cache 16 kB D-Cache Board: Sandpoint 8245 Unity ##Test not implemented yet## DRAM: 32 MB FLASH: Spansion_S29GL032M 4 MB Using default environment In: serial Out: serial Err: serial => setenv baudrate 57600 ## Switch baudrate to 57600 bps and press ENTER ... => flinfo Bank # 1: Brand: AMD Type: S29GL032M (32 Mbit, bottom boot sect) Size: 4096 KB in 71 Sectors Sector Start Addresses: FFC00000 FFC02000 FFC04000 FFC06000 FFC08000 FFC0A000 FFC0C000 FFC0E000 FFC10000 FFC20000 FFC30000 FFC40000 FFC50000 FFC60000 FFC70000 FFC80000 FFC90000 FFCA0000 FFCB0000 FFCC0000 FFCD0000 FFCE0000 FFCF0000 FFD00000 FFD10000 FFD20000 FFD30000 FFD40000 FFD50000 FFD60000 FFD70000 FFD80000 FFD90000 FFDA0000 FFDB0000 FFDC0000 FFDD0000 FFDE0000 FFDF0000 FFE00000 FFE10000 FFE20000 FFE30000 FFE40000 FFE50000 FFE60000 FFE70000 FFE80000 FFE90000 FFEA0000 FFEB0000 FFEC0000 FFED0000 FFEE0000 FFEF0000 FFF00000 RO FFF10000 RO FFF20000 E FFF30000 E FFF40000 E FFF50000 E FFF60000 E FFF70000 E FFF80000 E FFF90000 E FFFA0000 E FFFB0000 E FFFC0000 E FFFD0000 E FFFE0000 E FFFF0000 E =>
Last edited by jens (2008-01-09 21:16:08)
Offline
Well I still need to run oyt and get that 10K resistor to try this out.
If I can get this running, my long term plan:
(Flash layout, mtd1 - 64K, mtd2 - 64K, ramdisk - 3M, U-Boot - 64K, Kernel - .9M)
To add more functionality to U-Boot we need more memory. I don'[t think it is feasible to change the starting address, so we will have to take it from the Kernel that follows U-Boot. I think that the kernel partition is already full so I'm thinking about rearranging everything. ( Kernel 1M, Ramdisk - 2M, U-Boot - .8M, mtd4 - 64K, mtd5 - 64K ).
Any thoughts?
Offline
With this new U-Boot, will we be able to boot via tftp?
Offline
qn1234 wrote:
With this new U-Boot, will we be able to boot via tftp?
That would be my goal. Unfortunately I've never had steady hands and this surface mount stuff is very small. I got some 10K surface mount resistors, but got the wrong size. I tried to make them fit, but I'm just not steady enough. I'll have to get the right size and hope I can get those to soldered.
Offline
beattie wrote:
original: (Flash layout, mtd1 - 64K, mtd2 - 64K, ramdisk - 3M, U-Boot - 64K, Kernel - .9M)
To add more functionality to U-Boot we need more memory. I don'[t think it is feasible to change the starting address, so we will have to take it from the Kernel that follows U-Boot. I think that the kernel partition is already full so I'm thinking about rearranging everything. ( Kernel 1M, Ramdisk - 2M, U-Boot - .8M, mtd4 - 64K, mtd5 - 64K ).
Any thoughts?
Yeah,
Hmm. U-boot will probably only need 256k max space for itself (with network support and extras) - i have mine under 128k right now. It will probably only need a single sector (64k) for storing u-boot environment vars in flash.
Only issue I can see is that the first 64k of flash is divided into 8k sectors (broken up into smaller blocks perhaps for use like nvram style config data, etc?), and the remaining sectors of flash to the end are all 64k.
I also can't really see where U-boot is starting at 0xfff00000 instead of at flash base of 0xffc00000 - could this boot base be hardcoded in the SoC flash (0xff000000) or somewhere else?
Also Beattie, for the Surface mount resistor, i just pulled a larger one off of an old 3com network card that i had laying around. It was slightly larger than the pads, so I had to do a little bit of tricky soldering to get it to sit in the right place.
Other u-boot issues that will need work:
* pci memory map? pci init? (pci command doesnt work right now)
* maybe if pci init/mapping is worked out, this will allow boot from usb mass storage?
* porting ipg (ip1000a) linux 2.6 driver source to u-boot
* memtest doesnt seem to be doing anything right now
edit:
http://buffalo.nas-central.org/index.php/Flash_ROM
some alternative possibly flash layouts
Last edited by jens (2008-01-17 07:21:25)
Offline
Well,
I do have u-boot 1.3.1 working, somewhat. patch against u-boot 1.3.1 is attached; use at your own risk.
It compiles a working u-boot of about <128k. Writes/stores u-boot env/config data of 8k at sector 0xff004000
No net or usb/disk storage support yet (hopefully somebody else can work on this one), but lots of other great features.
Im having troubles getting a 2.6 kernel to get any serial console output after loading from uboot. Ive tried booting the original kernel, and it works just fine (at least up to kernel panic attempting to mount rootfs), so it has to be something to do with the new config/kernel. I'm reading something about dts? (which I'm totally unfamiliar) and wonder if it has anything to do with it.
U-Boot 1.3.1 (Jan 22 2008 - 13:08:56) CPU: MPC8245 Revision 1.2 at 199.999 MHz: 16 kB I-Cache 16 kB D-Cache Board: Sandpoint 8245 I2C: ready DRAM: 32 MB FLASH: Spansion_S29GL032M 4 MB In: serial Out: serial Err: serial => bootm ffc10000 ## Booting image at ffc10000 ... Image Name: Linux-2.6.24-rc8dsmg600 Created: 2008-01-23 3:24:48 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1411649 Bytes = 1.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK
I have tried bootargs of console=uart,mmio,0xfc004500,115200n8 as well as console=ttyS0,115200n8 with no luck. I'll get the kernel config posted up soon.
I wish there were 30 hours in a day!
edit: oh yes
I'm building uboot (and kernel stuff) with ELDK 4.1
"export CROSS_COMPILE=ppc_6xx-" and appropriate paths in my bashrc
and building kernel with ARCH=ppc (as opposed to powerpc?)
I did make sandpoint_defconfig, and then make menuconfig to mod the config there, but I'm seeing now that there are specific board options in sandpoint.h (like serial port irq/io addrs, etc)
looks like more fun ahead!!
Last edited by jens (2008-01-24 07:44:26)
Offline
jens wrote:
I wish there were 30 hours in a day!
Yeah, that would be awesome.
Offline
well alot of hacking left to do, but kernel is actually booting, but just taking like 1 minute before it will display any console output on serial
U-Boot 1.3.1 (Jan 22 2008 - 13:08:56) CPU: MPC8245 Revision 1.2 at 199.999 MHz: 16 kB I-Cache 16 kB D-Cache Board: Sandpoint 8245 I2C: ready DRAM: 32 MB FLASH: Spansion_S29GL032M 4 MB In: serial Out: serial Err: serial => bootm ffc10000 ## Booting image at ffc10000 ... Image Name: Linux-2.6.24-rc8dsmg600 Created: 2008-01-29 22:44:27 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1411732 Bytes = 1.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK
then a 1 minute delay before console output...
Linux version 2.6.24-rc8dsmg600 (jens@crash.local) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #10 Tue Jan 29 16:44:22 CST 2008 Motorola SPS Sandpoint Test Platform Port by MontaVista Software, Inc. (source@mvista.com) Zone PFN ranges: DMA 0 -> 8192 Normal 8192 -> 8192 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 8192 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128 Kernel command line: console=ttyS0,115200n8 OpenPIC Version 1.2 (1 CPUs and 11 IRQ sources) at fc040000 PID hash table entries: 128 (order: 7, 512 bytes) time_init: decrementer frequency = 690.000074 MHz Warning: real time clock seems stuck! Console: colour dummy device 80x25 console [ttyS0] enabled Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) Memory: 29492k available (2136k kernel code, 716k data, 136k init, 0k highmem) SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Mount-cache hash table entries: 512 net_namespace: 64 bytes NET: Registered protocol family 16 PCI: Probing PCI hardware PCI: Cannot allocate resource region 1 of device 0000:00:00.0 usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 1024 (order: 1, 8192 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes) TCP: Hash tables configured (established 1024 bind 1024) TCP reno registered sysctl table check failed: /kernel/l2cr .1.31 Missing strategy Call Trace: [c1c0fe50] [c000ba24] show_stack+0x48/0x190 (unreliable) [c1c0fe80] [c0033288] set_fail+0x50/0x68 [c1c0fea0] [c00337e0] sysctl_check_table+0x540/0x730 [c1c0fef0] [c00337f4] sysctl_check_table+0x554/0x730 [c1c0ff40] [c001f894] register_sysctl_table+0x5c/0xac [c1c0ff60] [c02b929c] register_ppc_htab_sysctl+0x18/0x2c [c1c0ff70] [c02b2870] kernel_init+0x94/0x280 [c1c0fff0] [c0006098] kernel_thread+0x44/0x60 JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. JFFS2: default compression mode: priority io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) Generic RTC Driver v1.07 Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xfc004500 (irq = 25) is a 16550A serial8250.1: ttyS1 at MMIO 0xfc004600 (irq = 26) is a 16550A RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: module loaded 0000:00:0f.0: IC PLUS IP1000 1000/100/10 based NIC 0000:00:0f.0 cannot map MMIO Sundance Technology IPG Triple-Speed Ethernet: probe of 0000:00:0f.0 failed with error -5 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx AEC6280: IDE controller (0x1191:0x0008 rev 0x10) at PCI slot 0000:00:10.0 AEC6280: 100% native mode on irq 19 ide0: BM-DMA at 0xbffe00-0xbffe07, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xbffe08-0xbffe0f, BIOS settings: hdc:pio, hdd:pio ohci_hcd 0000:00:0e.0: OHCI Host Controller ohci_hcd 0000:00:0e.0: new USB bus registered, assigned bus number 1 ohci_hcd 0000:00:0e.0: request interrupt 17 failed ohci_hcd 0000:00:0e.0: USB bus 1 deregistered ohci_hcd 0000:00:0e.0: init 0000:00:0e.0 fail, -16 ohci_hcd: probe of 0000:00:0e.0 failed with error -16 ohci_hcd 0000:00:0e.1: OHCI Host Controller ohci_hcd 0000:00:0e.1: new USB bus registered, assigned bus number 1 ohci_hcd 0000:00:0e.1: irq 18, io mem 0xbfffc000 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected i2c /dev entries driver TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. Root-NFS: No NFS server available, giving up. VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "<NULL>" or unknown-block(2,0) Please append a correct "root=" boot option; here are the available partitions: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) Rebooting in 180 seconds..
Offline