DryOS - some success

DataGhost

jeff666
While you are on it, could you have a look at the NR-handling? I'm back at work and don't have much time anymore.

If we control NR, we should have a (mostly) complete port of trunk and can start to port the changes to a newer branch with more features.

Yeah... about that.... 😳 I'm cheating. For starters, the keyboard stuff seems to be a lot different, I haven't figured it out anyway (some functions don't exist and the layout seems to differ from both the S3 and the A720, though I could be terribly wrong). The only keys I can see now is the shoot key (none, half and full) and the power-'key' (the twist-wheel thingy). Both are still handled by the OS, I can use the shoot key for browsing through my on-screen hexdump if I'm using a locked memory card, because it won't take a picture in that case.
Anyway, what I did was... add a LONG delay to the boot process, so I have time to actually switch my SD card. As you can see in this short clip, I put in an 8GB SDHC card (not locked) and it re-reads it and that works just fine. I can take pictures now 😀 Anyway, I keep the gui code running from spytask and fetch the shoot-button status. When I press it, it'll reset a counter and it will keep resetting it until I release that button. I coded it so that it would save the contents of the RAW buffer as soon as I release it (counter > 1) :p So what I did was... shoot an image at a couple of seconds shutter time and release the shoot-button as soon as it's done shooting and busy calculating a dark frame. It'll save the buffer before that's done, and the OS will output a jpeg file after that.
I'm really not anywhere near actually hooking the shooting functions yet, so I can't really have a look, sorry. I'm still in the middle of my exams so I don't have a lot of time, either 😀

Anyway, in the meantime I got an idea... I can create several partitions on an SD card. I have 2 8GB SDHC cards and a 32MB card I got from canon (and several 2GB miniSD cards, but they're really for my phone). Now I found out that the OS will read only one partition ( http://dataghost.com/chdk/S5_parse_MBR.txt ) and completely ignore the other, so I'll have to do something about that. Now, as you can see in the code, it should really not be that hard to alter it so that it'll read the second partition instead of the first one (offset everything by 0x10). The thing is, I ran out of time for today and that code seems to be called at least from 5 entries in a jump table just above there, I haven't traced them back yet. If this works out, I can create a small FAT16 partition to boot CHDK and a large FAT32 partition which is then read by the camera after loading the code 😀 That way, it'll be possible to use large SDHC cards with CHDK, as they're becoming increasingly popular, I think.

intrinsic

DataGhost
I'm really not anywhere near actually hooking the shooting functions yet, so I can't really have a look, sorry. I'm still in the middle of my exams so I don't have a lot of time, either 😀

Given your lack of time would you please post your code so far, that way we can continue work on the S5 without having to duplicate your efforts.

Thanks,
intrinsic

DataGhost

Yeah, sure, but it'll be tomorrow at best (I'm going to get some sleep now). I also have an exam tomorrow and didn't study that much, so I hope I can quickly clean up the code a bit because it's a real mess, unless that's fine with you 😀 I'll also add some comments in a few places.

intrinsic

DataGhost
Yeah, sure, but it'll be tomorrow at best (I'm going to get some sleep now). I also have an exam tomorrow and didn't study that much, so I hope I can quickly clean up the code a bit because it's a real mess, unless that's fine with you 😀 I'll also add some comments in a few places.

Excellent, I look forward to your post ;oD

DataGhost

I'm sorry I haven't posted anything yet... I got this idea (regarding bootable SDHC cards) so I traced a lot of stuff and figured out that I wrongfully assumed the code was being called outside of the already-hooked stuff. With the current code, I'm looking at 7 more subroutines I need to bypass, 14 almost-worst-case and it's hooked *somewhere* in the absolute worst case. I already documented a bit of this in boot.c (I should really get some more formal documentation going, outside source files 😛 ), so you can even have a look at that if you want.
Anyway, because of that, I haven't really paid much attention to cleaning up the code a bit, making it readable, adding comments, commenting out junk... so I'll have a quick break and get to that straight away.

By the way, the next problem is that Windows completely ignores an SD-card partition's type and opens up the first one (and refuses to open the second one in any way), so I guess that'll be Linux-only or through USB.

Edit: there we go, http://stack.dataghost.com/chdk-dryos-s5is-20080110.tar.bz2. I hope I cleaned it up well enough, this should at least run 😀

jeff666

DDMan wrote:
could you maybe upload your latest CHDK port for the A720, so people like me can test things like DataGhosts findings.

I just removed some annoying debug-stuff and rebuilt the code with the correct addresses for RAW-support. It's just for testing, though.

If you enable raw in the ALT-Menu, a file called "rawtest.crw" will be saved to the card. No counter or anything like that, yet, but if you get a bunch of original Canon 16mb SD-cards more than one file won't fit anyway 😀

First the code: http://www.zshare.net/download/6386888cd05c7f/

Next an example, 4" exposure, F between 6 and 8 (don't remember exactly). It's a picture of my "chaos-dominates-order"-corner 😁
The lighting is a little difficult, since the scene is lit by a normal neon-lamp behind the sofa and the black-light lamp on it. The black border on the right is the end of the wall.

raw: http://img341.imageshack.us/my.php?image=rawtestxh7.jpg
cam-jpg: http://img184.imageshack.us/my.php?image=img1191cg1.jpg

Both images shot with 8mpx. Raw converted using DataGhost's dcraw-patch. Scaled down with gimp.
Here's the output of dcraw:

-> dcraw -v rawtest.crw
Loading Canon PowerShot S5 IS image from rawtest.crw ...
Scaling with black 36, multipliers 1.582762 1.000000 1.718605 1.000000
AHD interpolation...
Converting to sRGB colorspace...
Writing data to rawtest.ppm ...

I guess dcraw's whitebalance failed this one. The actual scene looks much more like the camera's jpeg.

I'm very anxious to see the port and will help as much as I can. By the way I'm a software developer as well, so if time allows it I will dive into programming too. 😉

I could use someone who finds the entrypoint for "GetParameterData". We need it for the filecounter. You made yourself familiar with IDA? 😀

DataGhost wrote:
Edit: there we go, http://stack.dataghost.com/chdk-dryos-s5is-20080110.tar.bz2. I hope I cleaned it up well enough, this should at least run 😀

Great. Now I don't have to write a hexdump-function myself 😀

Edit:
Just remembered a glitch I noticed when saving RAW.
I had the resolution of the jpeg set to 5mpx for the first try. The raw-file was full size (as expected), but the upper 10% of the image were overwritten with garbage. After changing to 8mpx I got the result I posted above. Probably the resolution needs to be set to maximum.

Cheers.

digit

Is the full IDA Pro version required? Or would I be able to get away with the freeIDA one?

jeff666

digit wrote:
Is the full IDA Pro version required? Or would I be able to get away with the freeIDA one?

Unfortunately the free one doesn't support ARM (just x86).

ewavr

Hi all,
I got for some days A720 and played with previous jeff's sources.
I made:
-add functions: mkdir, set(get)parameterdata (and correct RAW numbering)
-keyboard now works correctly (no shooting mode change in <alt> mode)
-RAW shooting with noise reduction

Still have a lot to do: ~~histogram~~, scripts etc....

src: http://ewavr.nm.ru/hdk/A720_001.ZIP (makefile's slightly modified for compliation under Windows)

edit: sorry, histogram works

DataGhost

Histogram still crashes my camera, but that's probably because I haven't looked into it yet 😀 I had more pressing issues that needed addressing :p

Like booting from a big SDHC card which requires FAT32. I managed to dump a function-call graph from IDA, so that greatly simplified locating the functions. Canon either planned this or it's just a very bad coincidence, but I only got it right on the last try. I first tried the shortest (number-of-subroutines-wise) paths to that MBR code, and of course, it turned out that the path required was the last one I actually tried, so I ended up cloning ALL 15 subroutines, good for a whopping 1500 lines and the assembler complaining it couldn't properly place the literal pool(s) by itself. I'll look into reducing that again, as I think I 'only' need 12 subroutines (the 3 small ones aren't necessary, the others are 🙁 ), unless someone knows a better way. In my opinion, it's worth it 😀

jeff666: do be sure to read the comments if you actually want to use the prev/next functions in the hexdump. Actually, while I'm writing this... you do have proper keyboard support so you probably don't need my stuff to make it compatible with the shoot button (which triggers two 'buttons' when I want only one). If you still want/need to use that code, however, I must tell you that I'm not entirely sure anymore what I changed exactly. It should work from the comments, but it might need adjusting 😀
About your raw image: yours also looks a bit greenish! What options did you pass to dcraw? I only use -k <somevalue>, I don't really know how the others are going to help me. I did use the whitebalance functions, but I just keep getting some sort of fog over my image unless I adjust it by hand. Maybe I'm just not used to postprocessing RAW images, though, you seem to be quite cool about that whitebalance.

ewavr

A720 - updated:
- added function IsStrobeChargeCompleted, corrected GetSystemTime (for DryOS)
- list of propertycase is updated

like all operators in uBasic working correctly

src & bin - http://ewavr.nm.ru/hdk/A720_002.ZIP

next step - upgrade to GrAnd's version?

upd: DNG4PS2 (0.2.2beta17 for Windows/Linux) now supports A720/S5 RAW (with color profile from A640).

DataGhost

ewavrupd: DNG4PS2 (0.2.2beta17 for Windows/Linux) now supports A720/S5 RAW (with color profile from A640).

Great! Works nicely 😀

Anyway, in the meantime I also managed to dismantle the SD lock on the S5, I can now boot from a locked 8GB SDHC card and shoot pictures / record movies over the (nearly) full 8 GB. Short movie demonstrating that if anyone cares. I forgot to set up an extra light so you can't really see what I'm pointing at... it's still understandable from the rest of the clip, though 😀

Now I don't think there is anything more to do besides doing the things that actually need to be done, the ones I've delayed all this time :p I'll see if I can get to it quickly. Some explanation on the A720 keyboard handling, hooking and such might be nice (I'm going to read the coe this afternoon, after work, I guess), even though the S5IS code seems to be a lot different. I don't know how it's done exactly for either camera yet.
Oh, there is one thing I can still do, expand the SDHC bootcode a bit so it'll actually determine whether or not the second partition is present and is a FAT32 partition (and/or some way to indicate that the first partition is not to be loaded as picture-partition). Any ideas on what's preferred would be nice, else I think I'll stick with "if there is a second partition and it is 0xb (W95 FAT32), use it".

jeff666

ewavr wrote:
A720 - updated:

Great. I'm really impressed. It does everything trunk is supposed to do. Raw works, NR-suppression works, keyboard works completely and even scripts run.

I'd like to see GrAnd's version now.

DataGhost wrote:
e is one thing I can still do, expand the SDHC bootcode a bit so it'll actually determine whether or not the second partition is present and is a FAT32 partition (and/or some way to indicate that the first partition is not to be loaded as picture-partition). Any ideas on what's preferred would be nice, else I think I'll stick with "if there is a second partition and it is 0xb (W95 FAT32), use it".

This will be really useful. Post the code when you're done and I'll port it to the A720. I don't have an sdhc but fooling around with partition tables isn't a big problem.

Cheers.

DataGhost

Yes, I'll do that after I finalized it. In the meantime, you can start locating and/or redirecting some functions... I posted a .txt file with a commented part of a subroutine, that's the stuff that happens in the S5. I found it by searching for 0x55, you should see something happen with 0xAA and 0x1FE/0x1FF nearby. It'll probably look quite similar to the S5 code. Once you've located that, you'll have to find all references to that subroutine (view->graphs->xref to, the button should be on the toolbar as well but then you'll know what it looks like 😀 ) and you have to relocate them all... at least, I do not know a better way of doing it. That's the bare minimum you need to you. You might notice a *LOT* of functions as some sort of web (http://stack.dataghost.com/S5_xref_to_MBR_parser.png), that all points to a sub which points to a sub which points to a sub which basically reboots the camera and has nothing to do with the code you're looking for. You'll have to edit the graph file (you can save it from the menu and reopen it by passing it as a commandline arg) to get just the useful bits (http://stack.dataghost.com/S5_xref_to_MBR_parser_better.png). I actually made a mistake in doing the XREF thing, so all graphs I uploaded so far point to the wrong subroutines, although the proper one is called from that one and there are no other xrefs. In one of the graphs I mistakenly 'corrected' it with yet another wrong subroutine, but I don't need it anymore. Keep that in mind if you want to use my graphs.

Also, you don't need an SHDC card to test it. I have two cardreaders, one can read SDHC and the other can't. The latter one has a write-protect bypass and is hooked to my server, so I preferred using a 2GB SD card instead. Just create a partition table with a small FAT16 partition and a large FAT32 partition, create the filesystems and you should be fine. Put some pictures on them that'll allow you to instantly see which partition is loaded so you don't have to go into the menu 😀

As for the SD Lock, did you get that bypassed yet? If not, I used my boot-delay to be able to switch the SD card (or unlock it 😀 ) just before the (temporarily hooked) diskboot subroutine. I modified my boot-delay to light up a different LED inside the diskboot subroutine. What I did next was... boot the camera, see if the second delay is called. If it is, you know that the code is actually executed. Now, boot the camera again, take out the SD card in the first bootdelay, unlock it and put the card back in there. If the LED doesn't light up now, the sub already returned so you'll be able to guess what code is responsible for that, and eventually which address is responsible.
Be warned, though, the first three ops in the diskboot subroutine (after saving registers to the stack) actually test to see if the subroutine was executed from the firmware. I guess it gets relocated somewhere or they did some debugging with that and forgot to comment out that code... anyway, uncomment those three lines or it won't work 😀

Oh yeah, the insane amount of code you need to copy to make this work (I'm at about 1800 lines of ASM now) causes the assembler to confuse itself. You need to add ".ltorg" somewhere to fix it, it's probably best to do that at the end of each subroutine, as that is the same layout as in the firmware.

So.. that is if you want to try it the hard way, although you do have to reproduce a large amount of these steps, I think. It'll probably all be a lot easier when I'm done with the code and upload it, possibly tonight (I'm in your timezone) but I can't promise anything. I do get the firm update menu when I put a PS.FI2 file on my SDHC card, but we do need all this code for autoloading. All this combined doesn't even seem to add a large delay to the boot process, the only extra delay I have is the debug led at the beginning 😀

Oh yes, there is just one downside to my method, though... Windows won't be able to access the FAT32 partition on the SDHC card this way. For removable devices, it refuses to read anything else than the first listed partition in ANY way, even through the disk manager. It also ignores the partition type and filesystem, it just reads the first partition in the table, regardless of it being readable. Other methods for possibly circumventing this problem, i.e. by using a GPT, are carefully thwarted by not supporting those on removable media. It works fine on Linux, though, but I'm sure there are plenty of Windows users around here as well.
Now I said 'first listed' partition, if you switch both partitions around in the MBR, Windows will read the correct one. Unfortunately, the camera shows the exact same behaviour, so it is not possible (as far as I know) to construct an SDHC card with a large FAT32 partition that is both readable in Windows and bootable to the camera. The only workaround would be to write a clientside application which switches the partitions around in the MBR (annoyance), or by writing a driver. Some card manufacturers apparently have software available to mark the card or reader as non-removable media, but I have been unable to locate such a tool as of yet.

ArtDen

DataGhost top_margin = 15;
left_margin = 24;

It is wrong. As I saw in RAW file, top_margin = 0, left_margin = 0 but masked area (width=27) are placed at right of sensor

DataGhost

OK, I just fixed the partition autodetection, it will now show the first non-first (heh) FAT32 partition to the camera. Works fine on a 32MB SD card with a FAT16 partition, works fine on an 8GB SDHC card with 32MB FAT16 and 8GB FAT32. It was only after I was done that I thought "what happens if the first partition is FAT32?" Silly me, "Oh, heh. It can't boot from FAT32 anyway!" But I guess this WILL cause problems if CHDK is started through the Firm Update menu, right? I'll look into that now, source will probably be available later this evening. Most of the original code is still intact, I only had to relocate/alter two lines.

Edit: OK, that fix was straightforward. I'm still thinking too much C, in ASM I can just jump into the middle of the loop, getting the wanted result 😀 It should work for completely FAT32-formatted cards now, however I don't know if I can test that yet. I prefer not to give it a try until I figure out what exactly the 'Firm update' feature does (just to be sure).
I'll try doing some code cleanup in a bit, so it won't be long anymore 😀

intrinsic

DataGhost
Ontopic: Strange, though... STRD seems to work fine for me, at least the compiler doesn't complain. I'm now just documenting some code, maybe I'll try running it again today. Anyway, not sure if it's useful, but I do remember seeing the compiler complain about it, though I just can't find where anymore: IDA disassembles 'MVN' as 'MOVL'. The latter is not known to the compiler, it should be replaced with MVN, which is the proper identification.

What version of gcc are you using in your toolchain? I'm working with gcc-3.4.6 and I've had to change the STRD's in your boot.c out for the two individual STR's that jeff666 is using.

Something else I've noticed, there are some oddities to the DryOS branch which prevent it from building on the windows tool chain (gets stuck in an infinite loop and eventually sh.exe crashes). I've now moved the trees over to my Linux desktop I've not had any issues (barring the STRD vs. STR issue) since. I assume it's a makefile issue because trunk builds fine under the windows toolchain and if I move the code from your branches into my trunk it gets past where it loops (building libs) but still fails in the end, I'll have a look over it at some stage and see if I can figure it out.

DataGhost

Oh yes, I'm still using 3.4.3, I haven't noticed any problems so/and I forgot to set up 3.4.6 to completely exclude oddities. They should be quite compatible, though, as i.e. distcc will allow these versions to work together.

One thing I ran into is that whenever I divide pixel_cnt (in gui_init) by ANY value (well, I only tried 500 and 512), my camera starts behaving strangely. If I divide by 500, the AF led turns on and my camera 'locks', the only thing that still works is the viewfinder but all buttons are dead. In the main.dump it looks like an infinite loop is created 😳 If I divide by 512 (should generate a simple shift), I still have control over the camera, though the AF led is still lit. If I take a picture, I hear the shutter do its job but the screen stays black and the camera stops responding. If I open the battery compartment it starts emitting a beep (when I slide the switch to open it) until I actually disconnect the power by opening it.
I'm still not sure what to think of it, it could be the first problem related to my compiler, but I do doubt that.

Edit:

ae4b8: e3a01064 mov r1, #100 ; 0x64
ae4bc: e1cd02f0 strd r0, [sp, #32]
ae4c0: e3a00078 mov r0, #120 ; 0x78
ae4c4: e1cd02f8 strd r0, [sp, #40]

That's fron my main.dump. It seems that not only my assembler supports the STRD instruction, it also keeps it intact as one instruction rather than two. Looks like there's something wrong with the 3.4.6 toolchain then...

Edit2: In the original firmware, the first STRD is E1CD02F0 and it seems to assemble to the exact same instruction. I decoded the instruction myself, it seems to be STRSH R0, [SP, #0x20]. This instruction is invalid, though, as the S-bit is not allowed for STR. My bad, it seems that this instruction is not supported anyway. Maybe this would cause an 'unknown instruction' interrupt somewhere, but the documentation seems to indicate that this won't happen for this instruction (encoding). I don't really know what it's supposed to do then.

Edit3: It does seem to be required, though... my camera won't boot when I replace STRD by STR or STRH or comment it out. If replacing it by two STR instructions fixes the problem, it seems that it does do the right thing then.

ewavr

It was hard work 😀, but I found some mathematical functions in A720:
NHSTUB(_log, 0xFFE3C8DC)
NHSTUB(_log10, 0xFFE3B820)
NHSTUB(_pow, 0xFFE3B990) - really huge!
and
NHSTUB(_sqrt, 0xFFE3DC44), ~~requires "STMFD SP!, {R4-R6,LR}" before call~~ - fixed

I lacked functions opendir,readdir,closedir 🙁 But there are functions - OpenFasrDir, ReadFastDir - it is not known how they work.

I hope to find other functions.

Current state:

NHSTUB(SleepTask, 0xFFC196d0)
NHSTUB(CreateTask, 0xFFC0BBC0)
NHSTUB(ExitTask, 0xFFC0BE50)
NHSTUB(AllocateMemory, 0xFFDD7DF4)
NHSTUB(ExecuteEventProcedure                  ,0xFFC0C27😎
NHSTUB(FreeMemory                             ,0xFFDD7DE0)
NHSTUB(GetCurrentTargetDistance               ,0xFFCFDB3C)
NHSTUB(GetSystemTime                          ,0xFFDD7EFC)
NHSTUB(ints_disable                           ,0xFFC0057😎
NHSTUB(ints_enable                            ,0xFFC005A0)
NHSTUB(memcmp                                 ,0xFFC0E8F0)
NHSTUB(memcpy                                 ,0xFFC71BF4)
NHSTUB(memset                                 ,0xFFE0E37C)
NHSTUB(Close                                  ,0xFFC1502C)
NHSTUB(Open                                   ,0xFFC15004)
NHSTUB(Read                                   ,0xFFC0A44😎
NHSTUB(Write                                  ,0xFFC150D😎
NHSTUB(Lseek 				      ,0xFFC1516C)
NHSTUB(strcmp                                 ,0xFFC0E88😎
NHSTUB(strcpy                                 ,0xFFC0E834)
NHSTUB(strlen                                 ,0xFFC0E8CC)
NHSTUB(TakeSemaphore                          ,0xFFC0BA5C)
NHSTUB(vsprintf, 0xFFC0E7B4)    // first sub called in FADBGPrintf
NHSTUB(GetFocusLensSubjectDistance,	 0xFFCFEF9C)    // returns 0. What's wrong?
NHSTUB(GetZoomLensCurrentPoint,           0xFFD02FDC)
NHSTUB(GetZoomLensCurrentPosition,        0xFFD03B5C)
NHSTUB(RefreshPhysicalScreen,		  0xFFD62184)
NHSTUB(GetPropertyCase,			 0xFFC59c2c)    // PT_GetPropertyCaseString
NHSTUB(SetPropertyCase,			 0xFFC50CC😎    // PT_SetPropertyCaseString
NHSTUB(VbattGet,                          0xFFC119A😎    
NHSTUB(kbd_read_keys, 0xFFC130CC)       // will be replaced in kbd.c
NHSTUB(kbd_p1_f, 0xFFC131D0)
NHSTUB(kbd_p1_f_cont, 0xFFC131DC)
NHSTUB(kbd_p2_f, 0xFFC12A1C)
NHSTUB(kbd_pwr_on, 0xFFC370E😎
NHSTUB(kbd_pwr_off, 0xFFC370C0)
NHSTUB(kbd_read_keys_r2, 0xFFC36B14)

NHSTUB(mkdir, 0xFFC153D0)
NHSTUB(GetParameterData, 0xFFD1C5B😎
NHSTUB(SetParameterData, 0xFFD1C52😎
NHSTUB(IsStrobeChargeCompleted, 0xFFC974E4)

NHSTUB(open,				 0xFFC0A1B0)
NHSTUB(write,				 0xFFC0A4A😎
NHSTUB(close,				 0xFFC0A260)
NHSTUB(lseek,				 0xFFC1516C)     // = Lseek
NHSTUB(read,                             0xFFC0A44😎     // = Read

NHSTUB(Fopen_Fut,                        0xFFC149D0)
NHSTUB(Fwrite_Fut,                       0xFFC14B10)
NHSTUB(Fclose_Fut,                       0xFFC14a10)
NHSTUB(Fread_Fut,                        0xFFC14ABC)
NHSTUB(Fseek_Fut, 0xFFC14BB0)
NHSTUB(Remove, 0xFFC15074)
NHSTUB(rename, 0xFFC15100)

NHSTUB(GetDrive_ClusterSize, 0xFFC3F4C4)
NHSTUB(GetDrive_TotalClusters, 0xFFC3F4F😎
NHSTUB(GetDrive_FreeClusters, 0xFFC3F564)
NHSTUB(LockMainPower ,  0xFFC5BF6C)
NHSTUB(UnlockMainPower, 0xFFC5BEC0)
NHSTUB(GetCurrentAvValue, 0xFFCFFCA😎
NHSTUB(MoveFocusLensToDistance, 0xFFDA657😎
NHSTUB(MoveZoomLensWithPoint, 0xFFD03A8😎
NHSTUB(SetZoomActuatorSpeedPercent, 0xFFC0095😎 // null stub

NHSTUB(_log, 0xFFE3C8DC)
NHSTUB(_log10, 0xFFE3B820)
NHSTUB(_pow, 0xFFE3B990)
NHSTUB(_sqrt, 0xFFE3DC44)

NHSTUB(malloc, 0xFFC039DC)
NHSTUB(free, 0xFFC03AB0)
NHSTUB(FreeUncacheableMemory, 0xFFC1987C)
NHSTUB(AllocateUncacheableMemory, 0xFFC1984😎

NHSTUB(rand, 0xFFC0E9F😎
NHSTUB(srand, 0xFFC0E9EC)


NHSTUB(stat, 0xFFC1523😎

// dryos Test
NHSTUB(phySw_p1, 0xFFC131D0)    // called from phySw
NHSTUB(phySw_p2, 0xFFC12A1C)    // called when phySw_p1 returns 1
NHSTUB(NewTaskShell, 0xFFC596B0)  // starts new shell on Console. GUI output?
NHSTUB(UIFS_WriteFirmInfoToFile, 0xFFD4A934) // should write 'A/FirmInfo.txt'
NHSTUB(dumpMemoryToFile, 0xFFC141Fa)         // writes a portion of memory into a file (char* filename, 0, (void*) src, int length)

edit: state updated, currently missing:

isdigit isspace isalpha isupper
strncmp strchr strncpy strcat strrchr strtol strpbrk
time utime localtime
qsort
opendir readdir closedir rewinddir

Format of stat structure changed in DryOS:

struct	stat
    {
    unsigned long	st_dev;		//?
    unsigned long	st_ino;		//?	
    unsigned short	st_mode;	//?	
    short		st_nlink;	//?	
    short		st_uid;		//?	
    short		st_gid;		//?	
    unsigned long	st_atime;	//?	
    unsigned long	st_mtime;	//?	
    unsigned long	st_ctime;	//?	
    unsigned long	st_size;	
    long		st_blksize;	//?
    long		st_blocks;	//?
    unsigned char	st_attrib;
    int			reserved1;	//	
    int			reserved2;	//
    int			reserved3;	//
    int			reserved4;	//
    int			reserved5;	//
    int			reserved6;	//
};

And also:
#define O_TRUNC 0x200
#define O_CREAT 0x100

DataGhost

Well, I'll probably not be home for the rest of the weekend, so I'll just post this progress update for jeff666... nothing substantial was changed besides this file and the entire SDHC handling + SDlock (which can be handled through the keyboard code, I read? I don't have that working yet so it's currently the only way for me) is contained in this file.

http://stack.dataghost.com/chdk/20080112-platform-s5is-sub-101b-boot.c

« Previous Page Next Page »