Hardware Direct / Spi/mmc Driver

[craigix]

Hello everyone,

I think its pretty well decided (by Rob ) that things are going hardware direct due to gameparks mess of setting up linux (They are like a brick wall on the kernel btw).

I have a beta GP2X but they still have the SD bug crashing it, even when they do fix it its still one big mess dev wise, 100kps reading speed? gcc2.9? No dualcpu? Linux taking 16m for mpg?

suggested on irc:

The best route is to patch uboot to jump to some custom loader code before linux, that should make it easy for users to set up. (assuming you can write from within linux)

An SPI/MMC (sd?) driver (assumed 1bit for now), ideally we don't want several people doing the same work twice, I know that some of the spanish guys have devkits too, but i'm not sure what they are doing exactly, if someone can get some information it would be interesting.

Rob, are you working on an mmc driver already?

So abandoning linux then... suggestions?

 

[mr.spiv]

Hello everyone,

I think its pretty well decided (by Rob ) that things are going hardware direct due to gameparks mess of setting up linux (They are like a brick wall on the kernel btw).

I have a beta GP2X but they still have the SD bug crashing it, even when they do fix it its still one big mess dev wise, 100kps reading speed? gcc2.9? No dualcpu? Linux taking 16m for mpg?

suggested on irc:

The best route is to patch uboot to jump to some custom loader code before linux, that should make it easy for users to set up. (assuming you can write from within linux)

An SPI/MMC (sd?) driver (assumed 1bit for now), ideally we don't want several people doing the same work twice, I know that some of the spanish guys have devkits too, but i'm not sure what they are doing exactly, if someone can get some information it would be interesting.

Rob, are you working on an mmc driver already?

So abandoning linux then... suggestions?

​

I thought.. once specs 'came' out that there would not be desire for Linux anymore.. At least that's my aim.. kinda..

 

[Squidge]

I think everyone agrees the best performance will be reached without linux.

I know both Robster and Mr Spiv have done SD interfaces for GP32, but I think only Robster got his working, so he's the perfect man for the job

Once it works nicely, I'd like to look at full SD 4-bit communications in the future, but this will of course take longer as we will need to reverse engineer stuff, as the specs are all NDA'd, so MMC is the best to start us with. It's still got to be faster than GPH's attempt of 100KB/sec.

I'm not sure if GPH use 1-bit or 4-bit, or even if they have used the builtin SD controller in the MMSP2 - they may have done it in pure software like the GP32. Time will tell, no doub't.

 

[mr.spiv]

I know both Robster and Mr Spiv have done SD interfaces for GP32, but I think only Robster got his working, so he's the perfect man for the job

​

Yeah.. my SD interface has a poltergaist. Software works for Rob, wiring works when tested wire by wire but still no go. I blame global warming about that.

 

[craigix]

Yeah, always planned but not this quickly, well not until the whole mess that gamepark have made became apparent.

however...

DJw has managed to get gcc4 working now under linux... so I guess both options are open.

 

[Robster]

I never said that Linux should be abandoned, just that my personal interest lies in getting stuff running on the raw hardware.

I do see a pre-linux loader, something to replace U-Boot, but I always thought it would boot Linux by default (even, boot Linux immediately unless a specific button is held down while powering up).

GPH is in a bit of a rush at the moment, and they aren't giving out the information that people need, but I do believe that they will get it together and having Linux available should enable people to make ports of eg. SDL games quite simply.

That said, I'm perfectly keen to do a SD driver. We don't need any NDA docs or reverse-engineering to get the thing working in 4-bit mode, I have all the specs here. That doesn't include encrypted content on SD cards of course, and I'll leave that one well alone because I imagine that GPH will be using that for their protection for commercial games. I for one would like to see at least some commercial games for this thing, even if I don't particularly believe that they will sell well.

Ah well, on to the SD stuff then

 

[Squidge]

If you think it'll take a similar timescale to do 4-bit instead of 1-bit, then go for it

What will you be using for the fat layer? Steal some code from a linux kernel?

Oh, and VFAT support (LFN's) would be nice

 

[mr.spiv]

If you think it'll take a similar timescale to do 4-bit instead of 1-bit, then go for it

What will you be using for the fat layer? Steal some code from a linux kernel?

Oh, and VFAT support (LFN's) would be nice

​

I have several nice onefile hw independent FAT implementations around and a few SD codes (tied to some specific hw but the command set is there).. Whatever.. Haven't spent too much time on those yet though.

 

[mr.spiv]

I know both Robster and Mr Spiv have done SD interfaces for GP32, but I think only Robster got his working, so he's the perfect man for the job

​

Yeah.. my SD interface has a poltergaist. Software works for Rob, wiring works when tested wire by wire but still no go. I blame global warming about that.

​

Oh yeah.. the SD interface for GP32 showed some life yesterday, so there is hope :blink:

 

[DJWillis]

4bit would be a big bonus. There are several code resources to get vFAT going so I don't see that being a big problem, that's a bit of polish that is worth adding IMHO.

Warning: Random ramblings of somebody who should be in bed below.

The more and more I read about U-Boot (and look at the source) the more I think it could do what we want regards raw hardware with some tweaking/rebuilding.

It looks like it is very possible (not easy maybe) to make it support the SD directly (maybe in MMC mode for ease via Linux MMC drivers as that seems to be what U-Boot uses) and once you have that (it has FAT/vFAT/JFFS2 etc. readers in there) you could boot a compressed Linux kernel and image from the SD (slow I know but great for testing), from the NAND or just run launcher.g2x from somewhere on the SD card.

I see it working something like…

Start U-Boot init,
Check for SD presence,
No – Boot NAND from 100000 where the stock kernel/ME/GPH stuff is.
Yes –
Check for JFFS2 partition on the SD card on the 1st partition with a kernel image on it.
Yes – Boot Kernel from it.
No – Look for /GP2XBIN/launcher.g2x on FAT partition and run if present. – If not boot NAND.

It needs a bit more thought, you get the idea though, U-Boot does some cool stuff but I can’t see any way to get some sort of call-back going on a soft reset, that’s WAY out of my league . That would be nice as you could have things like “Reboot to Linux” in the launcher. The docs hint at exposing some sort of stub you can see from a raw H/W mode app but I don’t quite see how it would work.

It could be extended I guess quite easily to cover things like directly boot the launcher if A is pressed, SD Linux if Start etc. as I am sure U-Boot could read those inputs easily enough. I don’t see having 2 images on the NAND is a big deal if U-Boot was tweaked, I think it would do it in it’s current state but I have yet to try that on the dev-kit .

 

[Squidge]

The programs I've run via uboot (compiled with GCC3.4.3) run as normal, and if I let control leave the program by just return'ing from main, I'm back at the uboot prompt, so I could see just modifying uboot's current param file could give us this:

nand read 0x???????? 0x?????? 0x100000  [load our program from NAND]
go 0x100000                             [run our proggy, runs if user wants linux]
nand read 0x1000000 0x40000 0x100000    [load linux from nand]
bootm 0x1000000                         [boot linux]