From: David F. <dav...@ya...> - 2004-09-05 04:25:10
|
I got a partly working SD card driver with u-boot on a non-gum card. u-boot needs more work with partition detection since it locks the starting block at 32 which is fine for most mmc cards (though not all). My SD cards starting (non-secure) partion is 97 so I can change the 32 to a 97 and compile for my SD, obviously auto detect is required. When compiled for SD fatinfo fatls & fatload all work fine. When auto detect (using partion table on card) works, I'll port it to the PXA. As far as linux is concered, if no SD driver exists I try to patch the MMC driver to get past the SD initialization then the standard MMC code will work. Craig, the linux driver stuff is where I may need some assistance, kernel compiles are a little to slow for my linux coding experience, iterations take too long... u-boot is my speed for now. David. |
From: David F. <dav...@ya...> - 2004-09-05 13:26:04
|
Craig, In u-boot, cpu/pxa/mmc.c mmc_dev.type = PART_TYPE_UNKNOWN is not correct. I believe this should be DEV_TYPE_UNKNOWN. you also need to add mmc_dev.part_type = PART_TYPE_DOS and also add CONFIG_DOS_PARTITION define to the u-boot config file. This will enable detection of the starting sector of the 1st partition on any mmc card. Progress on my S3C2410 SD/MMC driver is proceeding better than I anticipated. I intend of spending the next day on code cleanup then I'll try to tackle the PXA. If you want (once it is clean) I'll send you the code I've got so far. David. David Farrell <dav...@ya...> wrote: I got a partly working SD card driver with u-boot on a non-gum card. u-boot needs more work with partition detection since it locks the starting block at 32 which is fine for most mmc cards (though not all). My SD cards starting (non-secure) partion is 97 so I can change the 32 to a 97 and compile for my SD, obviously auto detect is required. When compiled for SD fatinfo fatls & fatload all work fine. When auto detect (using partion table on card) works, I'll port it to the PXA. As far as linux is concered, if no SD driver exists I try to patch the MMC driver to get past the SD initialization then the standard MMC code will work. Craig, the linux driver stuff is where I may need some assistance, kernel compiles are a little to slow for my linux coding experience, iterations take too long... u-boot is my speed for now. David. |
From: Craig H. <cr...@hu...> - 2004-09-05 16:26:28
|
Wow, sounds great. C On Sep 5, 2004, at 6:25 AM, David Farrell wrote: > Craig, > In u-boot, cpu/pxa/mmc.c mmc_dev.type =3D PART_TYPE_UNKNOWN > is not correct.=A0 I believe this should be DEV_TYPE_UNKNOWN. you > also need to add mmc_dev.part_type =3D PART_TYPE_DOS and also > add CONFIG_DOS_PARTITION define to the u-boot config file. This > will enable detection of the starting sector of the 1st partition on=20= > any > mmc card.=A0 Progress on my S3C2410 SD/MMC driver is proceeding > better than I anticipated.=A0 I intend of spending the next day on = code > cleanup then I'll try to tackle the PXA.=A0 If you want (once it is=20 > clean) > I'll send you the code I've got so far. > > David. > > David Farrell <dav...@ya...> wrote: > I got a partly working SD card driver=A0with u-boot on a non-gum card. > u-boot needs more work with partition detection since it=A0locks the > starting block at 32 which is=A0fine for most mmc cards (though not = all). > My SD cards starting (non-secure) partion is=A0=A097 so I can change = the > 32 to a 97 and compile for my SD, obviously auto detect is required. > When compiled for SD fatinfo fatls & fatload all work fine.=A0 When = auto > detect (using partion table on card) works, I'll port it to the PXA. > As far as linux is concered, if no SD driver exists I try to patch the > MMC driver to get past=A0the SD initialization then the standard MMC > code will work. Craig, the linux driver stuff is where I may need some > assistance, kernel compiles are a little to slow for my linux coding > experience, iterations take too long...=A0 u-boot is my speed for now. > David. > =A0 > =A0 |
From: Bouwens / M. <bou...@bl...> - 2004-09-05 17:21:50
|
Hi Craig, I just downloaded the build 68 stuff. It generates a new rot_fs_arm with 2101664 bytes length. Do you generate a new downloadable reference version? If not I might touch the flash using: 1. MMC a. copy the root_fs image onto the MMC, and stick the MMC into the waysmall b. power on the waysmall while watching its serial console. Stop u-boot before it boots, during the countdown by pressing a key. c. now at the u-boot prompt, first erase the FS area of flash: "erase 1:2-31" d. load the fs image from the MMC to RAM: "mmc;mmc;fatload mmc 1 0xa2000000 root_fs_arm.r24.gumstix-f" e. copy the fs image to flash from RAM: "cp.b 0xa2000000 0x40000 $2101664" Which is what you posted few days ago. Regards Robert |
From: Craig H. <cr...@hu...> - 2004-09-05 20:05:55
|
Yes, the is the procedure -- best though in the last step (cp.b), to use the u-boot environment variable $(filesize) which is set by the fatload command automatically to be the correct number. That is, the command becomes verbatim: cp.b a2000000 40000 $(filesize) I will be producing a new "blessed" rootfs image to post to sourceforge in the next few days, which is 99.9% likely to be r68. C On Sep 5, 2004, at 10:21 AM, Bouwens / Mehl wrote: > Hi Craig, > > I just downloaded the build 68 stuff. > It generates a new rot_fs_arm with 2101664 bytes length. > > Do you generate a new downloadable reference version? > > If not I might touch the flash using: > 1. MMC > a. copy the root_fs image onto the MMC, and stick the MMC into the > waysmall > b. power on the waysmall while watching its serial console. Stop > u-boot > before it boots, during the countdown by pressing a key. > c. now at the u-boot prompt, first erase the FS area of flash: "erase > 1:2-31" > d. load the fs image from the MMC to RAM: "mmc;mmc;fatload mmc 1 > 0xa2000000 > root_fs_arm.r24.gumstix-f" > e. copy the fs image to flash from RAM: "cp.b 0xa2000000 0x40000 > $2101664" > > Which is what you posted few days ago. > > Regards > > Robert > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Bouwens / M. <bou...@bl...> - 2004-09-06 08:17:57
|
Hi Craig, I'm unable to use the "mmc;mmc;fatload ..." command The system does not recognize my apacer mmc only card. Instead I used the lengthy kermit approach. It works with the build 68 retrieved from the repository. After a while I get: hci0 lilling stalled ACL connection 0d:xxxx hci0 ACL tx timeout I'll try a linksys bluetooth adapter and report the results. Regards Robert > -----Original Message----- > From: gum...@li... > [mailto:gum...@li...]On Behalf Of Craig > Hughes > Sent: Sonntag, 5. September 2004 22:06 > To: gum...@li... > Subject: Re: [Gumstix-users] Build 68 > > > Yes, the is the procedure -- best though in the last step (cp.b), to > use the u-boot environment variable $(filesize) which is set by the > fatload command automatically to be the correct number. That is, the > command becomes verbatim: > > cp.b a2000000 40000 $(filesize) > > I will be producing a new "blessed" rootfs image to post to sourceforge > in the next few days, which is 99.9% likely to be r68. > > C > > On Sep 5, 2004, at 10:21 AM, Bouwens / Mehl wrote: > > > Hi Craig, > > > > I just downloaded the build 68 stuff. > > It generates a new rot_fs_arm with 2101664 bytes length. > > > > Do you generate a new downloadable reference version? > > > > If not I might touch the flash using: > > 1. MMC > > a. copy the root_fs image onto the MMC, and stick the MMC into the > > waysmall > > b. power on the waysmall while watching its serial console. Stop > > u-boot > > before it boots, during the countdown by pressing a key. > > c. now at the u-boot prompt, first erase the FS area of flash: "erase > > 1:2-31" > > d. load the fs image from the MMC to RAM: "mmc;mmc;fatload mmc 1 > > 0xa2000000 > > root_fs_arm.r24.gumstix-f" > > e. copy the fs image to flash from RAM: "cp.b 0xa2000000 0x40000 > > $2101664" > > > > Which is what you posted few days ago. > > > > Regards > > > > Robert > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by BEA Weblogic Workshop > > FREE Java Enterprise J2EE developer tools! > > Get your free copy of BEA WebLogic Workshop 8.1 today. > > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Craig H. <cr...@hu...> - 2004-09-05 16:25:51
|
Complete buildroot compiles (apart from downloads) take just about 10=20 minutes on my box. Kernel rebuild once it's already built is about 45=20= seconds, thanks to ccache. Let me know if/when you're ready, and I can=20= give you a login on the box to do compiles there. For the SD/MMC switch, as a stop-gap to reading the partition table,=20 how about if you read 32 and it fails, retry with 97; if that fails=20 too, then error. C On Sep 4, 2004, at 9:24 PM, David Farrell wrote: > I got a partly working SD card driver=A0with u-boot on a non-gum card. > u-boot needs more work with partition detection since it=A0locks the > starting block at 32 which is=A0fine for most mmc cards (though not = all). > My SD cards starting (non-secure) partion is=A0=A097 so I can change = the > 32 to a 97 and compile for my SD, obviously auto detect is required. > When compiled for SD fatinfo fatls & fatload all work fine.=A0 When = auto > detect (using partion table on card) works, I'll port it to the PXA. > As far as linux is concered, if no SD driver exists I try to patch the > MMC driver to get past=A0the SD initialization then the standard MMC > code will work. Craig, the linux driver stuff is where I may need some > assistance, kernel compiles are a little to slow for my linux coding > experience, iterations take too long...=A0 u-boot is my speed for now. > David. > =A0 > =A0 |