OESF Portables Forum
Everything Else => Model Specific Forums => Distros, Development, and Model Specific Forums => Archived Forums => SIMpad forum => Topic started by: guylhem on September 06, 2005, 12:45:12 pm
-
Hello
Just to let you know the MMC has been soldered into the simpad, and the driver is being developped. Currently some basic tests (like powering on and off leds from a kernel module) work fine.
Attention - the picture on my website has the MMC card drawn backwards. it should read "Top view" instead of "bottom view".
I'll fix the picture.
Guylhem
-
Very good work Guylhem!
-
BTW before killing my bluetooth chip (my own fault) I could get reliably speed up to 230 400 kbit/s.
I will release my custom 2.4.25 (backported bluetooth stack, custom mmc driver, support for 128 Mb) as soon as the mmc driver works.... it *almost* does.
-
Does anyone know where to get those MD35 DECT module flatcable and/or connectors Guylhem is talking about in his Creating a "beautiful" Bluetooth module for the Siemens Simpad SL4 (http://www.externe.net/zaurus/simpad-bluetooth/)?
-
Does anyone know where to get those MD35 DECT module flatcable and/or connectors Guylhem is talking about in his Creating a "beautiful" Bluetooth module for the Siemens Simpad SL4 (http://www.externe.net/zaurus/simpad-bluetooth/)?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=94834\")
I don't know about the MD35, but for the MD32 or 34 try: [a href=\"http://www.tis-gmbh.de/md32-34.html?&L=1]http://www.tis-gmbh.de/md32-34.html?&L=1[/url]
-- hns
-
Why would one need a cable if flying leads could easily be soldered?
Any technical details on what "almost working" means in this context?
-albertr
-
I don't know why I needed a cable - maybe to make a pretty module that can easily be plucked out of the simpad for improvement, so that everytime I had to solder/unsolder stuff on it, I could do that easily without risking frying the simpad motherboard :-)
Regarding the "almost working" :
# insmod simpad-mmc.o
mmc: GPIO init
mmc: initialising MMC
GPIO_SD_CS dir: 1 alt: 0
GPIO_SD_DI dir: 1 alt: 0
GPIO_SD_DO dir: 0 alt: 0
GPIO_SD_CS dir: 1 alt: 0
mmc: card init 1/2
mmc: card init 2/2
mmc: card init 3/3
Size = 249856, hardsectsize = 512, sectors = 499712
Partition check:
mmc/disc0/disc: p1
# cat /etc/fstab|grep mmcroot@simpad:~# cat /etc/fstab |grep mmc
/dev/mmc/disc0/part1 /mnt/mmc ext2 defaults,sync,noatime 0 0
# mount /mnt/mmc
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/root 24320 20440 3880 84% /
tmpfs 61868 36 61832 0% /var
/dev/mtdblock/2 8192 6492 1700 79% /home
/dev/hda1 125034 45654 79380 37% /mnt/cf
/dev/mmc/disc0/part1 241949 20 229437 0% /mnt/mmc
Sweet- 256 Mb in R/W on my simpad ! Along with my 128 Mb of RAM and internal bluetooth, it makes it a nice machine - the ultimate Zaurus once I get my Sandisk wifi+128 Mb CF working inside !
Currently merging home and root on the mtdblock - I will put Qtopia, my home and everything else (/opt) on mmc instead...
The driver only needs to be powersaving aware to be complete. (ie when receiving a apm suspend signal, finish its operation, and reinit the card on resume)
Anyway for now, and after some tests, I consider it a 99% success. The remaining 1% (powersaving) will be fixed when necessary.
The files will soon be available on my website.
Guylhem
-
http://externe.net/zaurus/simpad-bluetooth/ (http://externe.net/zaurus/simpad-bluetooth/)
Everything has been uploaded. Enjoy
-
This is very interesting, indeed. I'm wondering what read/write performance you did achieve on the mmc...
-
What do you want me to run to test it ? some timed dd ? give me a command line and I'll test it.
-
How about this:
date ; dd bs=4096 count=10000 if=/dev/zero of=/mnt/mmc/test ; sync ; date
This will write 40MB to the MMC and flush the cache. Then reboot to clean the cache and reread the file:
date ; cat /mnt/mmc/test > /dev/null ; date
-
Thanks for clarification, but I would like to see the output of `ls -la /mnt/mmc` at least
What particular brand of card do you use? It would be interesting to see tests of reading/writing from/to MMC simultaneously with high I/O activity of CF card to see if there's any timing problems under stress conditions. Someting like mounting NFS/SAMBA volume over CF wired/wireless link, and then do something like this:
cd /mnt/nfs; tar cvf - . | (cd /mnt/mmc; tar xvpf - )
and then compare MD5 sums, of course...
-albertr
-
root@simpad:/mnt/mmc# date ; dd bs=256k count=64 if=/dev/zero of=/mnt/mmc/test ;sync; date
Thu Sep 8 17:15:19 UTC 2005
64+0 records in
64+0 records out
Thu Sep 8 17:17:19 UTC 2005
root@simpad:/mnt/mmc#
root@simpad:/mnt/mmc#
root@simpad:/mnt/mmc# ls -l test
-rw-r--r-- 1 root root 16777216 Sep 8 17:15 test
(reboot)
root@simpad:/mnt/mmc# date ; cat /mnt/mmc/test > /dev/null ; date
Thu Sep 8 17:13:23 UTC 2005
Thu Sep 8 17:15:22 UTC 2005
16384/120=136 ko/s in read, same in write. Not so bad.
Regarding corruption, don't worry. I've put binaries- they haven't been corrupted :-)
-
Sounds promising.... So, you haven't experienced any problems? How long are you using it? I'll try to give it a shot when time permits, being very busy lately.
-albertr
-
I've soldered a SD/MMC socket to Simpad and was trying to use guylhem's driver. Unfortunately, I'm having problems with 32MB MMC card that I have.
Sometimes I'm getting the following error messages:
mmc: GPIO init
mmc: initialising MMC
GPIO_SD_CS dir: 1 alt: 0
GPIO_SD_DI dir: 1 alt: 0
GPIO_SD_DO dir: 0 alt: 0
GPIO_SD_CS dir: 1 alt: 0
mmc: card init 1/2
mmc: card init 255 error
GPIO_SD_CS dir: 1 alt: 0
GPIO_SD_DI dir: 1 alt: 0
GPIO_SD_DO dir: 0 alt: 0
GPIO_SD_CS dir: 1 alt: 0
mmc: card init 1/2
mmc: card init 255 error
mmc: error 1 in mmc_card_init
mmc: error -1 in mmc_init
Sometimes it gets alittle bit further, but I still get errors:
mmc: GPIO init
mmc: initialising MMC
GPIO_SD_CS dir: 1 alt: 0
GPIO_SD_DI dir: 1 alt: 0
GPIO_SD_DO dir: 0 alt: 0
GPIO_SD_CS dir: 1 alt: 0
mmc: card init 1/2
mmc: card init 2/2
mmc: card init 3/3
Size = 31360, hardsectsize = 512, sectors = 62720
Partition check:
mmca:end_request: I/O error, dev 79:00 (mmc), sector 0
end_request: I/O error, dev 79:00 (mmc), sector 2
end_request: I/O error, dev 79:00 (mmc), sector 4
end_request: I/O error, dev 79:00 (mmc), sector 6
end_request: I/O error, dev 79:00 (mmc), sector 0
end_request: I/O error, dev 79:00 (mmc), sector 2
end_request: I/O error, dev 79:00 (mmc), sector 4
end_request: I/O error, dev 79:00 (mmc), sector 6
unable to read partition table
Either way, so far I was not able to do anything useful with this card on Simpad. The card has a single primary partition type 6 that is formated FAT16. It works fine in my cell phone, notebook and two different Zauruses.
It looks it's able to read card's physical parameters sometimes, so wiring must be correct. Any idea what could be wrong?
I'll try to find some old Sandisk 128MB SD card that I have somewhere and give it a try too.
-albertr
-
The same problem with 128MB SD card made by Sandisk.
mmc: GPIO init
mmc: initialising MMC
GPIO_SD_CS dir: 1 alt: 0
GPIO_SD_DI dir: 1 alt: 0
GPIO_SD_DO dir: 0 alt: 0
GPIO_SD_CS dir: 1 alt: 0
mmc: card init 1/2
mmc: card init 2/2
mmc: card init 3/3
Size = 123008, hardsectsize = 512, sectors = 246016
Partition check:
mmca:end_request: I/O error, dev 79:00 (mmc), sector 0
end_request: I/O error, dev 79:00 (mmc), sector 2
end_request: I/O error, dev 79:00 (mmc), sector 4
end_request: I/O error, dev 79:00 (mmc), sector 6
end_request: I/O error, dev 79:00 (mmc), sector 0
end_request: I/O error, dev 79:00 (mmc), sector 2
end_request: I/O error, dev 79:00 (mmc), sector 4
end_request: I/O error, dev 79:00 (mmc), sector 6
unable to read partition table
This one has a primary partition type "b" - W95 FAT32.
Guylhem, what card do you use? Can you post its partition table info?
-albertr
-
[img]http://ak.buy.com/db_assets/prod_images/490/10359490.jpg\" border=\"0\" class=\"linked-image\" /]
If some1 may want to use a mmc/SD socket here is a cheap choice (got it at 19$ from amazon :-( two weeks ago
linky (http://www.buy.com/retail/product.asp?sku=10359490&adid=17662)
-
The price for a SD/MMC socket varies from $1 to $3 depending on make.
I would like to see someone else got the driver working, thou. I didn't have much time to debug it, but it doesn't seem to work in my setup, and I'm not sure what I'm doing wrong either...
-albertr
-
albertr, you must reread the partition of the card with forcepart. It's a simple ioctl. Tell me if it's not on the site, I'll upload it.
This is due to a bug in the current driver - it tries to read the partition table too early. Yet after that it works fine. To try out, try fdisk : pretend to make changes (say delete and recreate the same partition) then exit. It will send this ioctl.
This bug will be fixed in the next version which will also bring power management (for now you must umount before suspend or you'll have fs corruption)
-
Guylhem, thanks for explanation. Do you mean BLKRRPART ioctl()? When/How should I issue it? I.e. load the driver, make ioctl() call, then re-load the driver? I'm not sure since when driver is unloaded, device is gone, so no ioctl's can be made.
I'll give it a shot tonight when get back home.
-albertr
-
Still no go...
Here's the simple code that I'm trying to execute as per your suggestion (it's borrowed from fdisk code):
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define BLKRRPART _IO(0x12,95) /* re-read partition table */
#define BLKGETSIZE _IO(0x12,96) /* return device size */
#define BLKFLSBUF _IO(0x12,97) /* flush buffer cache */
#define BLKSSZGET _IO(0x12,104) /* get block device sector size */
#define BLKGETSIZE64 _IOR(0x12,114,size_t) /* size in bytes */
int
main(int argc, char **argv) {
int fd = 0, error = 0;
int i;
char name[] ="/dev/mmc/disc0";
// char name[] ="/dev/mmcda";
if ((fd = open(name, O_RDWR)) < 0) {
if ((fd = open(name, O_RDONLY)) < 0) {
printf("Failed to open %s, error[%d]: %s\n",
name, error, strerror(error));
exit(1);
}
}
printf("Calling ioctl() to re-read partition table.\n");
sync();
sleep(2);
if ((i = ioctl(fd, BLKRRPART)) != 0) {
error = errno;
} else {
/* give it another chance */
sync();
sleep(2);
if ((i = ioctl(fd, BLKRRPART)) != 0)
error = errno;
}
if (i) {
printf("Re-reading the partition table failed with error %d: %s.\n",
error, strerror(error));
}
if (fsync(fd) || close(fd)) {
printf("Error closing %s\n", name);
exit(1);
}
exit(0);
}
Here's the output I'm getting:
# ./fc
Calling ioctl() to re-read partition table.
Re-reading the partition table failed with error 25: Inappropriate ioctl for device.
Error closing /dev/mmc/disc0
What I'm doing wrong?
-albertr
-
Hello
It's not exactly what I use. My code is pasted below. Please send that ~ 1 to 2 seconds after the insmod. I use /dev/mmc because I don't like "dynamic" /dev filesystems.
#include
#include
#include
#include
#include
#include /* BLKRRPART */
#include
int main(void) {
char *device = "/dev/mmc";
int fd, err;
fd = open(device, O_RDONLY | O_NONBLOCK);
if (fd < 0) {
fprintf(stderr, "cannot open %s\n", device);
exit(1);
}
err=ioctl(fd, BLKRRPART);
if (err) {
if (EBUSY == err) {
fprintf(stderr, "%s : device busy\n", device);
// perror("EBUSY");
exit(-1);
}
if (EIO == err) {
// perror("EBUSY");
fprintf(stderr, "%s : no partition defined\n", device);
exit(-1);
}
perror("BLKRRPART");
exit(-1);
}
return 0;
}
-
Hah! I'm a dumbass! I was using the wrong device name, it's /dev/mmc/disc0/disc, and I was trying to open /dev/mmc/disc0 which was a devfs directory
I'm happy to report that driver works. I didn't do much of the testing yet, but at least I can mount a partition and read/write files.
It definitely looks promising... Great work, Guylhem!
-albertr
-
I put some pictures here:
http://www.iral.com/~albertr/linux/simpad/mmc/ (http://www.iral.com/~albertr/linux/simpad/mmc/)
-albertr
-
I put some pictures here:
http://www.iral.com/~albertr/linux/simpad/mmc/ (http://www.iral.com/~albertr/linux/simpad/mmc/)
-albertr
[div align=\"right\"][a href=\"index.php?act=findpost&pid=98763\"][{POST_SNAPBACK}][/a][/div]
Looks good. Hard to tell the slot wasn't put there at the factory!
-
That's what dremel is capable of
-albertr
-
Hah! I'm a dumbass! I was using the wrong device name, it's /dev/mmc/disc0/disc, and I was trying to open /dev/mmc/disc0 which was a devfs directory
I'm happy to report that driver works. I didn't do much of the testing yet, but at least I can mount a partition and read/write files.
It definitely looks promising... Great work, Guylhem!
-albertr
[div align=\"right\"][a href=\"index.php?act=findpost&pid=98658\"][{POST_SNAPBACK}][/a][/div]
Thanks for the compliment albert :-) I saw you where using 3.3 from the JTAG. If you use my schema, you can use cs3 to control the power - thus cutting power to the bluetooth and the MMC while on sleep mode.
BTW, I'd be very interested in making a beautiful hole like you did. Where are you located? May I bring you/send you my simpad? I suck at cutting hole in plastic, and I fear I'll do an awful job compared to what you did.
I'd also be very happy to discuss with you the project I'm currently working on- a GSM addon to the simpad. I've some prototypes around, and I'm wondering what's the best option (hooking the GSM module to the external serial port, or using another bluetooth chip, to connect to it via bluetooth serial profile, and have a SCO connection to the cellphone while keeping the 1st bluetooth chip bandwith totally available for other applications, such as network connection. In the latter case, I'd be like having a bluetooth cellphone inside the simpad, only using its power and smartcard slot to access the SIM)
Guylhem
-
I'm not good in cutting thru plastic too, but dremel was very handy. I'm curious how much current idle SD/MMC card is consuming? Might try to measure it sometime later to be certain. I'm planning to modify serial driver to send the break signal when port is closed, this way CSR bluetooth module would enter deep sleep mode to save the power.
Not really sure about serial GSM module, I don't have any experience with these. Besides, I always carry a cell phone with me anyway, but using Simpad only once in a while as a GPS navigation device.
I'm located in Eastern PA, USA.
-albertr
-
Well that's a bit far from Europe. I'll try to play with a dremel to see what I can do with some training :-)
Guylhem
-
@Guylhem: How did you compile the kernel module?
I used the kernel 2.4.25 from your homepage, but I got many errors.
Maybe you can post the command line or a Makefile?
thx
Sascha
-
Hello
I simply copy/paste a module compilation command line. You can try to put the latest mmc.c you can find on the page in the kernel directory where the old mmc.c is. Alternatively, I can send you a binary if you want to test.
PS: IIRC you're into hardware mods too. May I ask you to give me a hard in flash upgrading of the simpad?
Guylhem
-
PS: IIRC you're into hardware mods too. May I ask you to give me a hard in flash upgrading of the simpad?
Guylhem
[div align=\"right\"][a href=\"index.php?act=findpost&pid=100983\"][{POST_SNAPBACK}][/a][/div]
That's right, I upgraded my T-sinuspad Flash.
In short:
I soldered a second 16mb Flash with soldering paste and an hot-air-pen on the free pads.
But no idea how to upgrade the flash more than 32 mb.
I was not able to find any flash chips i could pay
And I also dont know how often you can desolder (is it correct?) and solder again,
until the pads loose their adhesive!?
-
Hello
I found some nor flash chips references that should be compatible, but I couldn't pruchase them.
If you are interested in attempting to sodler them, I will do my best to find them. I don't think soldering/resoldering should be a problem, as long as you don't damage anything
Guylhem
-
At the moment I try to get my 512mb sd card to work.
I think a half gigabyte additional storage should be enough
The problem is that with your image the mmc driver ist working, but I can not load the needed hostap
version for my Sundisk Connect+.
-
Can the simpad MMC module be considered stable enough to be included in the mainstream kernel (2.4.27) ?
I'm wondering how solid it is, considering the comments at the top of the code...
-
fredyd, it's not stable enough - it needs power management support (if you suspend with a mounted partition, there's corruption...) will do that sometime
sash, did you succeed in having both the hard disk part and wifi part at the same time? I could under wince, I can't on linux. IIRC it's due to not applying some voltage, ie a driver problem.
Guylhem
-
@Guylhem: You were right - it's a driver problem.
I think first it was the actual pcmcia-cs package which does not support binding two
modules/driver to the same slot. And second nobody definitivly knows which initialising
command(s) are used to tell the connect+ to run in wifi+storage mode
Thus I soldered the sc-card to extend the memory.
Can you help me a little bit further to compile the module for an actual kernel?
I tried the following with the kernel from oe-tree:
1. modified the kernel-patch to enable mmc support (CONFIG_MMC=y)
2. replaced the linux/drivers/mmc/mmc_core.c with your mmc driver
If I compile the kernel using bitbake, a mmcdrivers.o and mmc_core.o is generated.
But both of them produce no output when I load them. insmod reports something from tainted kernel module.
IIRC it is only a warning and the module should function anyhow!?
lsmod reports that the module is loaded, but there is no dev/mmc directory.
Any ideas?
btw: The power management support could be released by the apm scripts.
I did the same with wpa_supplicant on my laptop: Unloading for suspend and reloading on wakeup.
-
Well, I'm not Guylhem, but here's how I've compiled it inside the kernel tree - just put Guylhem's mmc.c file into linux/drivers/block directory and added the following:
"tristate 'MMC SPI driver' CONFIG_BLK_DEV_MMC"
to linux/drivers/block/Config.in
and
"obj-$(CONFIG_BLK_DEV_MMC) += mmc.o"
to linux/drivers/block/Makefile
`make menuconfig` then choose "MMC SPI driver" to compile as a module.
That should do it.
Don't enable MMC support that exists in the latest kernels, it has nothing to do with this driver.
As far as power management goes, I think Guylhem is right. The driver needs hooks to apm to properly re-init the card after loss of power. I have my card powered up all the time, so I don't have this problem, but power drain even in idle mode seems to be significant, so I'm planning to re-wire it to some controlled 3.3V domain. Removing/Reloading the driver on apm events is not an option with storage devices IMHO, since it would invalidate its mount state. I'm not sure what would happen if the card is used as a swap device/file in this case...
-albertr
-
@albertr: It works - thanks
I have made a kernel path for actual opensimpad kernel from openembedded repository.
If guylhem (or somebody else) would load it up to his webspace anybody could
compile the driver and make an ipk easily by replacing the original patch before
compiling the kernel.
I think you're right - it's not a good idea to power down/unmount the card with an
opened file.
Do you know how much current your card needs during standby?
Maybe I also let my card always powered on until the power management in implemented.
-
I didn't measure it yet - still didn't get around to open my Simpad again. But I left it suspended for a week with a fully charged battery and it drained it completely before I tried to resume it.
-albertr
-
sash, I'd be happy to host the patch, but IMHO it should be send to Frederic Devernay who host images on his website.
BTW, what about restarting more officially the opensimpad project?
I'd like to see my kernel in the opensimpad project, until we or someone else finds some time to work on 2.6
Guylhem
-
BTW, what about restarting more officially the opensimpad project?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=102599\"][{POST_SNAPBACK}][/a][/div]
The opensimpad project was integrated into the openembedded tree.
Or what did you mean with "restarting the opensimpad project"?
So I thing we only have to contact one of the oe guys to integrate the patch to the oe-tree.
Maybe we could help them to maintain the simpad part of the project!
My problem is that I am not close with irc where most of the discussions take place.
But I'd help as good as possible.
-
about restarting opensimpad
see the new topic
restart opensimpad (https://www.oesf.org/forums/index.php?showtopic=15990)
thomas
-
Sash sent me the MMC driver, and after a few fixes (kernel compile warnings) I commited it to OpenEmbedded (it's a module after all, so it won't bother people who don't use it).
It's also easier to make images for the t-sinuspad or the 128Mb simpad from OE (see the instructions at the beginning of opensimpad-64+0_2.4.27-vrs1-pxa1-jpm1.bb)
The new images with MMC support will be ready quite soon (tomorrow?).
I wish someone could work on sound support now... Guylhem, won't you need it for your GSM module?
Fred
sash, I'd be happy to host the patch, but IMHO it should be send to Frederic Devernay who host images on his website.
BTW, what about restarting more officially the opensimpad project?
I'd like to see my kernel in the opensimpad project, until we or someone else finds some time to work on 2.6
Guylhem
[div align=\"right\"][a href=\"index.php?act=findpost&pid=102599\"][{POST_SNAPBACK}][/a][/div]
-
From the OE commit log:
opensimpad: MMC support + better support for SinusPad and 128M SIMpad
- There's now a config option to build the kernel for 128Mb SIMpad
(as there was one for the SinusPad)
- The .bb files automatically turn on these options depending on the
total memory available.
- The MMC driver was made by Clement Ballabriga <clement@asso.ups-tlse.fr>
and Guylhem Aznar <simpad@externe.net>.
Adding an MMC card (internal or external) to the SIMpad is described
on these pages:
http://externe.net/zaurus/simpad-bluetooth/ (http://externe.net/zaurus/simpad-bluetooth/)
http://www.iral.com/~albertr/linux/simpad/mmc/ (http://www.iral.com/~albertr/linux/simpad/mmc/)
-
Hello
I'd rather work on 2.6 than fixing 2.4
By restarting opensimpad, I mean putting images somewere (say - on opensimpad.org !) the feeds, etc. fixing bugs and issues with the images..
Fredyd, if I put my tarball somewhere, could you find a way to submit its fixes into OE?
(ex: apm addons, screen corruption switches, switchd daemon)
Guylhem
-
Unfortunately, you'll have to break down the various fixes into patches to each package, to be applied after the previous patches (the 2.4.27 kernel for example is linux-2.4.27 with no less than 22 patches). That's the way OE works (and it is the best way to do it), so you should pull OpenEmbedded, and work on patches to each package. Don't you use OpenEmbedded? If not, you definitely should.
BTW, the sound problem in 2.4 is exactly the same as in 2.6, since the ucb1x00 driver didn't change.
fred
Hello
I'd rather work on 2.6 than fixing 2.4
By restarting opensimpad, I mean putting images somewere (say - on opensimpad.org !) the feeds, etc. fixing bugs and issues with the images..
Fredyd, if I put my tarball somewhere, could you find a way to submit its fixes into OE?
(ex: apm addons, screen corruption switches, switchd daemon)
Guylhem
[div align=\"right\"][a href=\"index.php?act=findpost&pid=103304\"][{POST_SNAPBACK}][/a][/div]
-
Hello,
I've been following this thread for a while now, and I know this is blastphemy to even ask this on this site, but does anyone know if I can do the same on my simpad , it is running windows ce 4.0?
I would like to keep my sd card installed all the time and add my wifi card or network card without loosing my sd card. I would like to retain the current os, as I am not that familiar with linux.
I do have very good soldering skills so I have issues with the hardware part of the mod.
Any help would be greatly appreciated.
Thanks Tom
please email me with any responses at tomd007@ameritech.net
Unfortunately, you'll have to break down the various fixes into patches to each package, to be applied after the previous patches (the 2.4.27 kernel for example is linux-2.4.27 with no less than 22 patches). That's the way OE works (and it is the best way to do it), so you should pull OpenEmbedded, and work on patches to each package. Don't you use OpenEmbedded? If not, you definitely should.
BTW, the sound problem in 2.4 is exactly the same as in 2.6, since the ucb1x00 driver didn't change.
fred
Hello
I'd rather work on 2.6 than fixing 2.4
By restarting opensimpad, I mean putting images somewere (say - on opensimpad.org !) the feeds, etc. fixing bugs and issues with the images..
Fredyd, if I put my tarball somewhere, could you find a way to submit its fixes into OE?
(ex: apm addons, screen corruption switches, switchd daemon)
Guylhem
[div align=\"right\"][a href=\"index.php?act=findpost&pid=103304\"][{POST_SNAPBACK}][/a][/div]
[div align=\"right\"][a href=\"index.php?act=findpost&pid=103343\"][{POST_SNAPBACK}][/a][/div]
-
Hello,
I've been following this thread for a while now, and I know this is blastphemy to even ask this on this site, but does anyone know if I can do the same on my simpad , it is running windows ce 4.0?
I would like to keep my sd card installed all the time and add my wifi card or network card without loosing my sd card. I would like to retain the current os, as I am not that familiar with linux.
I do have very good soldering skills so I have issues with the hardware part of the mod.
Any help would be greatly appreciated.
Thanks Tom
please email me with any responses at tomd007@ameritech.net
That would require someone to write a driver for Windows CE, which requires a special SDK that costs hundreds of dollars to license.
Your best bet is to get your feet wet with Linux, you might find that it isn't as hard as you thought.
-
Hello,
I've been following this thread for a while now, now i flashed my Sl4 with Opie and i had insert a mmc card (512 mb) ,but it would not be run, Im not so familiar with linux, also i could not install any driver.
So my question is, have anyone an runnig opie Image for me, with mmc and wlan support, bestly with Guylhem skript to reread the card.
Also with a running Opera,that would be graet.
Please send it to mailto://peppe@uni.de
Thanks Peppe