DryOS - some success - page 10 - DryOS Development - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 5 6 7 8 9 [10] 11 12 13 14 15 ... 23   Go Down

DryOS - some success

  • 220 Replies
  • 165590 Views
*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: DryOS - some success
« Reply #90 on: 10 / January / 2008, 22:11:19 »
Advertisements
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).

« Last Edit: 11 / January / 2008, 04:07:03 by ewavr »
Logged
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: DryOS - some success
« Reply #91 on: 11 / January / 2008, 07:34:22 »
Quote from: ewavr on 10 / January / 2008, 22:11:19
upd: 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".
Logged
*

Offline jeff666

  • ****
  • 181
  • A720IS
Re: DryOS - some success
« Reply #92 on: 11 / January / 2008, 08:13:34 »
Quote from: ewavr
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.

Quote from: DataGhost
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.
Logged
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: DryOS - some success
« Reply #93 on: 11 / January / 2008, 09:19:02 »
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.
« Last Edit: 11 / January / 2008, 14:22:06 by DataGhost »
Logged
*

Offline ArtDen

  • ***
  • 175
    • dng4ps2
Re: DryOS - some success
« Reply #94 on: 11 / January / 2008, 11:11:24 »
Quote from: DataGhost on 09 / January / 2008, 11:54:48
    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
« Last Edit: 11 / January / 2008, 11:21:55 by ArtDen »
Logged
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: DryOS - some success
« Reply #95 on: 11 / January / 2008, 16:11:47 »
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 :)
« Last Edit: 11 / January / 2008, 16:22:59 by DataGhost »
Logged
*

Offline intrinsic

  • *
  • 29
  • S5IS
Re: DryOS - some success
« Reply #96 on: 11 / January / 2008, 20:36:53 »
Quote from: DataGhost on 05 / January / 2008, 16:27:34
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.
Logged
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: DryOS - some success
« Reply #97 on: 12 / January / 2008, 04:45:20 »
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:
Quote
   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.
« Last Edit: 12 / January / 2008, 06:54:27 by DataGhost »
Logged
*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: DryOS - some success
« Reply #98 on: 12 / January / 2008, 06:41:45 »
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:
Code: [Select]
NHSTUB(SleepTask, 0xFFC196d0)
NHSTUB(CreateTask, 0xFFC0BBC0)
NHSTUB(ExitTask, 0xFFC0BE50)
NHSTUB(AllocateMemory, 0xFFDD7DF4)
NHSTUB(ExecuteEventProcedure                  ,0xFFC0C278)
NHSTUB(FreeMemory                             ,0xFFDD7DE0)
NHSTUB(GetCurrentTargetDistance               ,0xFFCFDB3C)
NHSTUB(GetSystemTime                          ,0xFFDD7EFC)
NHSTUB(ints_disable                           ,0xFFC00578)
NHSTUB(ints_enable                            ,0xFFC005A0)
NHSTUB(memcmp                                 ,0xFFC0E8F0)
NHSTUB(memcpy                                 ,0xFFC71BF4)
NHSTUB(memset                                 ,0xFFE0E37C)
NHSTUB(Close                                  ,0xFFC1502C)
NHSTUB(Open                                   ,0xFFC15004)
NHSTUB(Read                                   ,0xFFC0A448)
NHSTUB(Write                                  ,0xFFC150D8)
NHSTUB(Lseek       ,0xFFC1516C)
NHSTUB(strcmp                                 ,0xFFC0E888)
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, 0xFFC50CC8)    // PT_SetPropertyCaseString
NHSTUB(VbattGet,                          0xFFC119A8)   
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, 0xFFC370E8)
NHSTUB(kbd_pwr_off, 0xFFC370C0)
NHSTUB(kbd_read_keys_r2, 0xFFC36B14)

NHSTUB(mkdir, 0xFFC153D0)
NHSTUB(GetParameterData, 0xFFD1C5B8)
NHSTUB(SetParameterData, 0xFFD1C528)
NHSTUB(IsStrobeChargeCompleted, 0xFFC974E4)

NHSTUB(open, 0xFFC0A1B0)
NHSTUB(write, 0xFFC0A4A8)
NHSTUB(close, 0xFFC0A260)
NHSTUB(lseek, 0xFFC1516C)     // = Lseek
NHSTUB(read,                             0xFFC0A448)     // = 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, 0xFFC3F4F8)
NHSTUB(GetDrive_FreeClusters, 0xFFC3F564)
NHSTUB(LockMainPower ,  0xFFC5BF6C)
NHSTUB(UnlockMainPower, 0xFFC5BEC0)
NHSTUB(GetCurrentAvValue, 0xFFCFFCA8)
NHSTUB(MoveFocusLensToDistance, 0xFFDA6578)
NHSTUB(MoveZoomLensWithPoint, 0xFFD03A88)
NHSTUB(SetZoomActuatorSpeedPercent, 0xFFC00958) // 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, 0xFFC19848)

NHSTUB(rand, 0xFFC0E9F8)
NHSTUB(srand, 0xFFC0E9EC)


NHSTUB(stat, 0xFFC15238)

// 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:
Code: [Select]
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
« Last Edit: 19 / January / 2008, 06:55:44 by ewavr »
Logged
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: DryOS - some success
« Reply #99 on: 12 / January / 2008, 12:05:55 »
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
Logged
Pages: 1 ... 5 6 7 8 9 [10] 11 12 13 14 15 ... 23   Go Up
« previous next »
 

Related Topics