Re: Managed to brick my sheevaplug -- not getting any serial output
Is it necessary for me to use the same mini-usb cable that came with the
sheevaplug? It seems my host machines ( windows, linux, mac) all recognize
the sheevaplug but when I try connecting to the serial port I get
nothing...
I think I am running into the same problem with the installer as well,
.
jtag_nsrst_delay: 200
jtag_ntrst_delay: 200
dcc downloads are enabled
Error: unable to open ftdi device: device not found
Runtime error, file command.c, line 469:
openocd FAILED
Is the mini USB cable connected?
Try powering down, then replugging the Sheevaplug
This particular snapshot is from my windows box, but I have installed the
ftdi driver and the USB Serial Device shows up both under Device Manager
and putty seems to connect on the correct COM4 port, but just doesn't show
anything
On Wed, Mar 10, 2010 at 1:48 PM, Martin Michlmayr t...@cyrius.com wrote:
* Lluís Batlle virik...@gmail.com [2010-03-10 22:41]:
The plugcomputer.org wiki or places like that will give you
information on how to do that.
Exactly. Search for installer v1.0.
--
Martin Michlmayr
http://www.cyrius.com/
Re: Managed to brick my sheevaplug -- not getting any serial output
I threw my cable away months ago after big problems with it disconnecting serial access. Now I just use any mini-USB cable lying around. On Thu, Mar 11, 2010 at 09:18, Shiva Bhattacharjee shiva...@gmail.com wrote: Is it necessary for me to use the same mini-usb cable that came with the sheevaplug? It seems my host machines ( windows, linux, mac) all recognize the sheevaplug but when I try connecting to the serial port I get nothing... I think I am running into the same problem with the installer as well, . jtag_nsrst_delay: 200 jtag_ntrst_delay: 200 dcc downloads are enabled Error: unable to open ftdi device: device not found Runtime error, file command.c, line 469: openocd FAILED Is the mini USB cable connected? Try powering down, then replugging the Sheevaplug This particular snapshot is from my windows box, but I have installed the ftdi driver and the USB Serial Device shows up both under Device Manager and putty seems to connect on the correct COM4 port, but just doesn't show anything On Wed, Mar 10, 2010 at 1:48 PM, Martin Michlmayr t...@cyrius.com wrote: * Lluís Batlle virik...@gmail.com [2010-03-10 22:41]: The plugcomputer.org wiki or places like that will give you information on how to do that. Exactly. Search for installer v1.0. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/3005d6291003110154s6b556cadx9873f55a11df1...@mail.gmail.com
Re: Managed to brick my sheevaplug -- not getting any serial output
2010/3/11 Shiva Bhattacharjee shiva...@gmail.com: Is it necessary for me to use the same mini-usb cable that came with the sheevaplug? It seems my host machines ( windows, linux, mac) all recognize the sheevaplug but when I try connecting to the serial port I get nothing... I think I am running into the same problem with the installer as well, . jtag_nsrst_delay: 200 jtag_ntrst_delay: 200 dcc downloads are enabled Error: unable to open ftdi device: device not found Device not found? Are you sure your system has /dev/ttyUSB0 in place, after connecting the cable? You should configure openocd to access that device. In a typical udev-enabled linux, you will see /dev/ttyUSB0 only with the cable connected. Regards, Lluís. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/45219fb01003110229n36771deemd43ddc401bd25...@mail.gmail.com
Re: 2nd try: Thermaltake Muse NAS-RAID (N0001LN) - IOP architecture - HELP requested
Hi, after the (usual) long delay I've managed to fight my jet-lag with a good coffee and I've tested the image Arnaud provided me with :) The steps I've followed are: 1. halt the startup sequence at Redboot prompt with CTRL+C 2. *RedBoot fis load ramdisk.gz* 3. *RedBoot load -r -v -h 192.168.1.122 -b 0x01008000 -m tftp zImage_2633_iop32x_defconfig* (since Redboot comes up preconfigured with an IP address I've chosen tftp) This step ends with the following message: *Raw file loaded 0x01008000-0x01279aaf, assumed entry at 0x01008000* 4. *RedBoot exec -c console=ttyS0,115200 rw root=/dev/ram0 init=/linuxrc initrd=0xa180,8M mem=2...@0xa000 force_ep80219* At this point the startup sequence goes on pretty normal until it stops with errors (RAMDISK) eventually terminating in a kernel panic (full sequence is attached). What's the meaning of the hex addresses in the above commands? Are they hardcoded in the image or do they just point to (almost) arbitrary addresses? Thanks, -mw On Thu, Feb 25, 2010 at 10:52 AM, Arnaud Patard arnaud.pat...@rtp-net.org wrote: Mello mello...@gmail.com writes: Hi, So, basically, I must stop the startup sequence at a point where I can gain access to the Redboot prompt. Then issue the commands you suggested, right? Questions: 1. where do I find/how can I generate such a kernel? I've build one for you. It's based on the 2.6.33 kernel (tbh, no patches were added). I've not tested it but it should work. You'll find it here: http://www.rtp-net.org/ss4000e/zImage_2633_iop32x_defconfig You can load it with (for instance) : load -v -r -b 0x01008000 -m ymodem zImage I've choose the ymodem upload method but things like http should work too (as long as the redboot has been configured/compiled correctly) Oh, and don't forget to load the initrd and launch the kernel with the commands I gave before :P 2. what happens to my device after doing this test? Will it revert to normal after a power-cycle or do those command overwrite the flash/disk somehow? the 'load' command is safe as it loads the kernel/initrd into memory. Nothing should be modifying it, so, after a poweroff/reboot, you'll go back to the normal state. Arnaud $ screen /dev/tty.usbserial 115200 +Ethernet eth0: MAC address 00:40:d0:8a:1f:99 IP: 192.168.1.11/255.255.255.0, Gateway: 192.168.1.1 Default server: 192.168.1.122, DNS server IP: 0.0.0.0 RedBoot(tm) bootstrap and debug environment [ROM] Intel IOP RedBoot release version 2.2.V6-IOP-RedBoot built 13:51:51, Jan 12 2006 Platform: EP80219 (XScale) Copyright (C) 2000, 2001, 2002, Red Hat, Inc. RAM: 0x-0x1000, 0x00021790-0x0ffd1000 available FLASH: 0xf000 - 0xf080, 64 blocks of 0x0002 bytes each. == Executing boot script in 1.000 seconds - enter ^C to abort ^C RedBoot fis load ramdisk.gz RedBoot load -r -v -h 192.168.1.122 -b 0x01008000 -m tftp zImage_2633_iop32x_defconfig --- Raw file loaded 0x01008000-0x01279aaf, assumed entry at 0x01008000 RedBoot exec -c console=ttyS0,115200 rw root=/dev/ram0 init=/linuxrc initrd=0xa180,8M mem=2...@0xa000 force_ep80219 Using base address 0x01008000 and length 0x00271ab0 The boot tags are located at 0xA100 Booting the kernel... Uncompressing Linux... done, booting the kernel. Linux version 2.6.33 (r...@jules) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #1 Wed Feb 24 21:57:47 CET 2010 CPU: XScale-80219 [69052e20] revision 0 (ARMv5TE), cr=397f CPU: VIVT data cache, VIVT instruction cache Machine: Intel IQ31244 Memory policy: ECC disabled, Data cache writeback Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: console=ttyS0,115200 rw root=/dev/ram0 init=/linuxrc initrd=0xa180,8M mem=2...@0xa000 force_ep80219 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 256MB = 256MB total Memory: 246400KB available (4652K code, 301K data, 148K init, 0K highmem) Hierarchical RCU implementation. RCU-based detection of stalled CPUs is enabled. NR_IRQS:32 clockevent: iop_timer0 uses shift 32 mult 0x clocksource: iop_timer1 uses shift 29 mult 0xa000 Console: colour dummy device 80x30 Calibrating delay loop... 398.95 BogoMIPS (lpj=1994752) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok xor: measuring software checksum speed arm4regs : 257.600 MB/sec 8regs : 287.600 MB/sec 32regs: 274.800 MB/sec xor: using function: 8regs (287.600 MB/sec) NET: Registered protocol family 16 PCI: bus0: Fast back to back transfers disabled pci :00:01.0: BAR 0: assigned [mem 0x8000-0x8001] pci :00:01.0: BAR 0: set to [mem 0x8000-0x8001] (PCI address [0x8000-0x8001]
Re: Help needed to debug an armel build/unittest failure
On 3/7/10, Iustin Pop iu...@k1024.org wrote: So it looks like what we're actually seeing here is one bit of corruption. I still strongly suspect a compiler bug. Probably the compiler's emulation of 64-bit arithmetic is broken in some way. First, are you aware of 64-bit arithmetic issues on arm(el)? No, I know of no 64-bit arithmetic issues in any armel GCC. OpenSSL uses 64-bit int math and its testsuite passes fine. The main ARM issue is requiring 4-byte alignment of 4-byte word accesses (and 2- of 2-) with silent data corruption if you access an unaligned word. You can test for that by going # echo 5 /proc/cpu/alignment and running your test again. On unaligned access the program will then die with SIGBUS instead of merrily going on its way with corrupted values. I thin The main ARM and armel idiosyncracies are listed at wiki.debian.org/ArmEabiFixes However, there are four versions of GCC - 4.[1234] - installed here if you'd like to probe that theory. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/56d259a01003110436w309f5a29mbecaf4dfc10f4...@mail.gmail.com
Re: Very newbe help/pointers required about building a distribution from scratch
(Add debian-embedded@ as Neil was suggesting) Hello, 2010/3/10 Jonathan Wilson piercing_m...@hotmail.com: What I'd like to know is how do I build a distribution entirely from scratch/source like the pro's do. linux from scratch is a great reference. ie. Get all the debian source for the latest arm port (just the source) and then compile/build it till I have a working system. Have you noticed packages like rebuildd[1] or apt-build[2]? [1] http://packages.debian.org/rebuildd || http://julien.danjou.info/rebuildd/ [2] http://packages.debian.org/apt-build -- Héctor Orón Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/dd0a3d701003110510i393986ebk7713fd51f33ac...@mail.gmail.com
Re: Very newbe help/pointers required about building a distribution from scratch
On 3/10/10, Luke Kenneth Casson Leighton l...@lkcl.net wrote: ... where is all this documented? has anyone actually done this - documented and automated e.g. how the debian-armel port was created, when previously there was only the debian-arm one? There is a huge difference between recompiling packages of an existing port with cpu-specific options and making a new port. I collected the closest I got to useful advice for a new port at the bottom of wiki.debian.org/ArmEabiPort I did most of the armel port in 2006, and after being pushed to cross-compile it by the emdebian crowd, it turned out this was impossible because you have to compile most packages natively on the same kind of Debian system. The armel port was mostly bootstrapped by updating Maemo, which was the first very early Debian armel system, if a bit rickety, aged and incomplete (and sometimes plain messy), repairing it as best one could then working up a spider's nest of dependencies between the 117 essential and required Debian packages, some of them circular, to get closer and closer to a full self-building native true Debian system. I got through 91 of them when in August my father was murdered in front of me. Wookey slurped up the .deb's I had built and Buytenhek completed the port in November/December - in his case by Debianizing an ARM EABI OpenEmbedded base system, as far as I can tell. I don't see how much of this could be automated, since every new port depends on the existing work in the field. However, in this case, cpu-optimization, the most effective way to build cpu-optimized packages is to make a wrapper script called gcc (and cc and gcc-4.3 and arm-linux-gnueabi-gcc) in some funny directory, which you prefix to the PATH variable passed in dpkg-buildpackage's environment. There is an example of this (for a rare FPU) at the bottom of the section http://martinwguy.co.uk/martin/crunch/#UsingIt I don't know of any tools to recursively find the runtime package dependency graph for you, but there are perl libraries that will interrogate the package lists for you. For your application you don't need to care about the order of the package build, just an unordered list of the packages that you require to populate your own local repository, then use that. Even easier, just make a rootfs for your system from the standard repository, then query the list of packages installed on that, rebuild those into your own repository, then reinstall your system from that. M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/56d259a01003110559k5e30411cv3bd13e65a59f7...@mail.gmail.com
Re: Managed to brick my sheevaplug -- not getting any serial output
Newer kernels don't use /dev/ttyUSB0 for JTAG. It is used for serial access and no /dev/ttyUSB1 will appear. Check out http://www.openplug.org/plugwiki/index.php/Setting_Up_OpenOCD_Under_Linux On Thu, Mar 11, 2010 at 11:29, Lluís Batlle virik...@gmail.com wrote: 2010/3/11 Shiva Bhattacharjee shiva...@gmail.com: Is it necessary for me to use the same mini-usb cable that came with the sheevaplug? It seems my host machines ( windows, linux, mac) all recognize the sheevaplug but when I try connecting to the serial port I get nothing... I think I am running into the same problem with the installer as well, . jtag_nsrst_delay: 200 jtag_ntrst_delay: 200 dcc downloads are enabled Error: unable to open ftdi device: device not found Device not found? Are you sure your system has /dev/ttyUSB0 in place, after connecting the cable? You should configure openocd to access that device. In a typical udev-enabled linux, you will see /dev/ttyUSB0 only with the cable connected. Regards, Lluís. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/45219fb01003110229n36771deemd43ddc401bd25...@mail.gmail.com -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/3005d6291003111400r4fd454d0se09997fdc0017...@mail.gmail.com
Re: Managed to brick my sheevaplug -- not getting any serial output
Just wanted to update for completeness. Got my plug working again using the Installer v1.0, while running from Ubuntu. Several people did mention that while running from windows they ran into issues as well. Apparently the FTDI drivers (at least on Windows 7) isn't exactly reliable from what I can tell... Btw, great work on the installer. Very good instructions... Thanks a lot for all your help. 2010/3/11 Björn Wetterbom bjohv...@gmail.com Newer kernels don't use /dev/ttyUSB0 for JTAG. It is used for serial access and no /dev/ttyUSB1 will appear. Check out http://www.openplug.org/plugwiki/index.php/Setting_Up_OpenOCD_Under_Linux On Thu, Mar 11, 2010 at 11:29, Lluís Batlle virik...@gmail.com wrote: 2010/3/11 Shiva Bhattacharjee shiva...@gmail.com: Is it necessary for me to use the same mini-usb cable that came with the sheevaplug? It seems my host machines ( windows, linux, mac) all recognize the sheevaplug but when I try connecting to the serial port I get nothing... I think I am running into the same problem with the installer as well, . jtag_nsrst_delay: 200 jtag_ntrst_delay: 200 dcc downloads are enabled Error: unable to open ftdi device: device not found Device not found? Are you sure your system has /dev/ttyUSB0 in place, after connecting the cable? You should configure openocd to access that device. In a typical udev-enabled linux, you will see /dev/ttyUSB0 only with the cable connected. Regards, Lluís. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/45219fb01003110229n36771deemd43ddc401bd25...@mail.gmail.com
