You can get the new image here: Zipit Z2 Development V2.torrent
Or here: http://thepiratebay.org/torrent/5392949/Zipit_Z2_Development_V2
NOTE: The seeding is not going as well as I had hoped on this torrent. If you are able, you should forward a port on your firewall/router for your bit-torrent client to use. That will allow you to download from a connection I have set up which is seeding at 300k. Also - if any of you would rather just get a copy of this development kit by mail, I am going to offer that service to you. I will send a disc to anyone in the US for a flat fee of $10. That should cover materials, postage, etc. Just PayPal $10 to donations AT oddree.com. If you would like a copy and you are outside of the US, please email me (ray AT oddree.com) and we can try and work something out. I see there are some Swede's in my seeds. :-)
The release notes are below, but here is a quick rundown ... This was built for VirtualBox and the guest edition tools are all ready installed. Instead of trying to share raw files again (sorry about that) this is being shared as an "exported appliance". Which means you could also use this with VMWare if you wanted to. Also, because buildroot has proven useful in a few areas involving kernel modules, I have included that too.
It's been suggested that I include a few pre-built packages. But not knowing what people will really use this for, I didn't want to "muddy the waters" of an otherwise clean build environment. Rather, I will build some packages of my choosing and then perhaps find a way to share those in a way that you can drop them into your VirtualBox (if anyone is interested?).
If you are having trouble using this, or if you have questions etc. drop me a comment to this post. You can email me too at ray AT oddree.com, but leaving comments is preferable if it's something others might benefit from reading.
RELEASE NOTES:
ABOUT
This is version 2 of the Zipit Z2 Development kit. You can use this kit to compile your own software for use on the Zipit Z2 from Zipit Wireless.
Included is a virtual appliance exported out of VirtualBox v3.1.4. This image should also work with VMWare. However, if you are using VMWare you will need to install the guest tools and possibly remove the included guest tools for VirtualBox.
The image includes a configured and ready-to-use Scratchbox environment and also a buildroot environment that includes a patched Z2 kernel and ALSA (thanks again, GPSFan).
INSTALLATION
Download and install VirtualBox from http://www.virtualbox.org. Click File > Import Appliance and then point to this torrent. Adjust your memory as you see fit (256MB is about as low as you should go - 1GB+ is probably overkill).
After booting up for the first time, you should be auto-logged on as "zipit". This users password is "password" (without the quotes). Note that the root password is also "password" and so you should change those if you are going to attach this device to a network!
MORE INFO
For more information - see the README.txt file on the Desktop of the virtual appliance, and the README.txt in the root of the Scratchbox home directory.
Check out www.oddree.com for more details and post-release notes and linux.zipitwireless.com for more on the Z2 device.
Hack on!
-Ray Dios Haque
February 2010
Posts
Are there any people that have developed stuff using this 'virtual machine' that you know of? If so could you link them?
ReplyDeleteThat's a good question. I see a lot of people downloaded the last one, and a couple more have jumped onto this latest seed. But unless they speak up - I don't know how they are using this. I hope they step forward and share their experiences!
ReplyDeleteAlso --- the seeding is not going as I intended. I started seeding this from home with an upload speed capped at 20k. Then I started it at work with an upload capped at 300k. I am now seeding 5 or so people at 20k and ZERO at 300k. The reason is - I have a port forwarded at home to a static IP, but I don't have that capability at work.
If any of you are getting inpatient waiting for this to finish, it is worth your while to get a port forwarded on your firewall/router. Then you can jump on that 300k bandwagon. ;-)
I suppose I should offer a disc-burning service to anyone who can't wait the three weeks to download this. I will add something into the post on this topic.
Howdy, I've got a 25k upload seeding for pretty much forever now (that is I'll leave it up for months, its work DSL and at low priority so no biggie). It took about 13 hours to get.
ReplyDeleteThat being said, thank you tons for this. I don't know really what I'm doing, but I did seem to be able to compile "vim", with hopes of running that, it does seem to run in the scratchbox, but once on the zipit it tells me no such file or directory, even when I run it directly ./ from that folder. I'm wondering if its looking for something else.
All I put on the sd card was the resulting "vim" file.
Anyhoo having fun trying to make stuff work, one day I'll get it :)
Thank you for this and the other re-seed sir. I had gotten caught up in the trials of workplace stress with a last minute trip to Asia. I am back and mostly caught up, so I have found this. Now that it is found, I will be here seeding with port forward 24/7 off my 1mbps home environment.
ReplyDeleteHey bobdole369: Thank your for seeding it back! I apologize for how long it took to download it. I have this great connection at work which is hardly being used because I don't have the ability to port forward to it. I think most folks were grabbing it from my home connection which is pretty slow.
ReplyDeleteI think I know your problem is with vim. When you compile things in scratchbox, it's using shared libraries. Then when you try to run them in the Z2 Shell, it doesn't understand how to run something with shared lib's. That "not found" error you are getting is not related to vim. Rather, what it's trying to pull is the binaries needed for shared libs. What you should do it get the latest IZ2S from this site. Then go into the bin directory of the archive and pull out a couple of files. They are ldd, ldconfig, and readelf. Put those into the bin folder on your SD card and try to run vim again. It may still fail - but at least it will fail with a more sensible error message! To see what else is needed in the way of shared libraries - run ldd /mnt/sd0/bin/vim. It should tell you what it needs and what it's not finding. Then it's just a matter of stealing those libs from your scratchbox.
You could also compile vim as a static binary. But that's not always as easy as it sounds. Theoretically you should be able to run 'CFLAGS=-static ./configure' when you are building it. But a lot of stuff ends up building dynamic anyway. Another thing to try is after you have built it in scratchbox, run 'file vim' (or whatever it is). This will tell you if it was build static or dynamic.
file vim was the quickest to do so:
ReplyDelete[sbox-Z2: /usr/local/bin] > file vim
vim: ELF 32-bit LSB executable, ARM, version 1 (ARM), dynamically linked (uses shared libs), stripped
SO immediately I can tell that it's not static. I did use the 'CFLAGS=-static ./configure' line, which resulted in a 1.89MB binary, vs. a 1.25MB one that I achieved with simply ./configure -> make -> make install So it did something, but not completely staticize (is that a word) the final binary.
GOnna get some grub and spend a bit more on this one.
Hey Bob, you got screwed over all right. I know the feeling. I have spent many an hour banging my head against the wall with software like this. The real bugger is that if you post to the developers list about it and tell them about the problem you will probably get into an argument with them about what "should and should not be static".
ReplyDeleteOne trick I discovered is that if you remove the resulting binary at the end of the build process (vim) and then rebuild it by running 'make' you will be able to catch that last line where the binary is created. It will start with gcc and then run on for several lines with all the *.o files, and possibly some linked libraries.
If you copy that line, and paste it right back into the terminal, then add -static to the end of it, you should get a static binary. Usually if you scroll back through the build process you will find that the gcc lines include "-static" right up to the point where the final product is produced.
Some have said that this is from a bug in ldconfig. I think it's because something is being left out in the Makefile or configure process myself. Not sure. But I do know that this trick usually works.
Hope that helps!
-Ray
Whelp we ended up with a 2.3MB binary that file vim now reports as "statically linked". It segfaults......
ReplyDeleteHow does one run the vmdk image? There's no vmx file, so it's not as easy as starting vmplayer; and when I try converting the ovf to a vmx, the ovftool generates lots of error messages. Is there some more direct way to use the image?
ReplyDeleteHello Ted,
ReplyDeleteIt sounds like you are performing the task correctly. I built this as an OVF file thinking that VMWare folks could use it easily. If you are getting error messages, that makes me think that one of the two products (VMWare/VirtualBox) are not following the standards properly.
Are you using the latest ovftool from VMWare? ...
http://www.vmware.com/downloads/download.do?downloadGroup=OVF-TOOL-1-0
I will have to try this myself - as I have only tested the image using VirtualBox. :-(
Yes, I downloaded the ovftool from VMware just two days ago. Searching on the problem turned up lots of hits (others experiencing similar things). Some suggest generating a "legacy" ovf, which may be a choice from virtualbox, I don't know.
ReplyDeleteWas able to put up the system from the vmdk image, but even compiling (static of course) hello.c gets segfault on the zipit. What kind of userland are you running?
ReplyDeleteHey Ted, I think I have to answer your question with some questions. Are you still running the "stock" OS on your Zipit, or have you replaced it with a different distro? I am assuming that you are running the stock - otherwise you would have been pulling some serious hacking to get this thing to boot!
ReplyDeleteWith the stock OS, you are running the 2.6.21-1 kernel that is written onto the firmware of the Z2. So when you are compiling code, you should be using scratchbox (which is installed on the development PC). I don't think that this really qualifies as a userland. You are running a real kernel, and your code runs off of that real kernel.
I haven't seen a segfault in a while now. Not since I was doing some horrible things with combining static and dynamic libs together. Obviously there is not much to a hello world example. Which makes me think that something went sour with your build environment, or en-route to your Zipit.
Nope, this one is running a 2.6.29 kernel, so maybe that's the mismatch problem. Still brings up the question of what is the proper base rootdisk (includes kernel etc) that matches the vmdk you had. The buildroot's .config doesn't even gen a kernel, without changing some make menuconfig options.
ReplyDeleteI realize this is about a year late, but for a few months now I've been building stuff for iz2s with this scratchbox environment and it works great! Thanks for providing this!
ReplyDeleteThe only thing I'm having trouble with is the ALSA lib. I built rockbox and several other programs but only the OSS compatibility part of ALSA works. The libasound.so file in the scratchbox env must've been compiled in buildroot (with a bad config) as it uses VFP instructions and thus won't link with anything built in scratchbox. However there is a libasound.so in iz2s that looks like it was built in scratchbox, and does indeed link with scratchbox built programs. However it looks for the config files in a cmus directory, and doesn't seem to work, perhaps due to a config file or version mismatch. I'd really like to use ALSA without the OSS compatibility layer, but I think I need help at this point to get to a build environment that works for alsalib, buildroot or scratchbox.
I'm often on the zipit IRC channel if you're not totally done with the zipit and want to help.