we already have universal dumper... why dont we have a universal loader? - page 2 - General Discussion and Assistance - CHDK Forum supplierdeeply

we already have universal dumper... why dont we have a universal loader?

  • 17 Replies
  • 6023 Views
*

Offline fe50

  • ******
  • 3099
  • IXUS50 & 860, SX10 Star WARs-Star RAWs
    • fe50
Re: we already have universal dumper... why dont we have a universal loader?
« Reply #10 on: 29 / October / 2008, 09:32:50 »
Advertisements
Hmmmmm, it sounds like the idea is mostly in the too hard basket.
...However, to clariify:
...A fat 'easyboot' version is *not* mutually exclusive with keeping the existing builds.
Thanks for all the comments.

Robocat, thx for your explanations.
Sometimes it may be a bit annoying (and also frustrating) to discuss such things, but imo it is absolutely necessary to talk about it & hear other opinions, also gathering different views...so this constructive discussion can go on  ::)

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: we already have universal dumper... why dont we have a universal loader?
« Reply #11 on: 29 / October / 2008, 14:00:15 »
Finally - I have 2 different Canon cameras that I want to use CHDK on. This concept would allow me to use the same cards between them.

That'll call for a separate cfg file for each camera too I think... Even if cfg files from different cameras are compatible in every way, there are features that are more useful on some cameras than others.

Re: we already have universal dumper... why dont we have a universal loader?
« Reply #12 on: 29 / October / 2008, 18:29:41 »
I'm really happy with everyones comments - basically you have pointed out some difficulties, and options. I have the skills to actually do the work, so all I need now is to give myself a kick in the arse (or give my job a kick in the arse!) and get on to it!

Also it has shown me just how active and friendly all the CHDK crew are - huzzahs all round! PhyrePhoX is an especially great guy -- he has already assigned me a TX1 bug to get me motivated ;)

Thanks guys and gals :)

*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: we already have universal dumper... why dont we have a universal loader?
« Reply #13 on: 29 / October / 2008, 19:04:14 »
you're very welcome :) looking forward to seeing your contributions, feel free to ask if questions arise, though you should always search the wiki/forum first, which i'm sure you already know :)


*

Offline reyalp

  • ******
  • 11920
Re: we already have universal dumper... why dont we have a universal loader?
« Reply #14 on: 29 / October / 2008, 23:33:23 »
Switching cards between cameras is an interesting question. My first thought was: "cards are cheap", but that's probably because my cam only supports SD. If you have a 32 gig SDHC or eyefi, I can see that point.

cfg handling is something that could use some attention anyway, so that would be worth keeping in mind if anyone decides to re-work it.

Whim is right, the cams that require encoded diskboot.bin would definitely require their own bootloader.

I think you could do a universal loader (aside from the exception above), at the cost of increased the boot time.  As others have said, this could be a major downside. How big a deal it was would depend somewhat on how big your loader had to be. If you are lucky, it could be only a KB, which wouldn't be noticeable.

Your initial universal loader would
- figure out what camera it is on. It's not clear what the best way to do it is, but I'd start with a table of address/byte squence that are unique to each camera. I would start out with platformid and firmware version string, which should be sufficient and relatively easy to find. Note that this would allow you to avoid searching ROM or hashing large parts of it, you'd just walk through a < 100 entry array comparing a couple of words for each. The time to do this would be inconsequential, especially compared to say reading a single block from the SD card. You might have to figure out the ROM start address first (by checking CP15, or looking for strings at FFC00000) to avoid invalid memory accesses.
- compiled in would be the minimal set of entry points required to load a file (indexed by the same index as your ID table), for each camera. This may be difficult, because the normal functions we use for file IO expect the OS to be loaded. However, the initial boot code that finds and loads diskboot.bin might be usable. It obviously understands enough FAT to find diskboot.bin, ps.fir and a few other things in the root, long before the full OS is booted. Look around FFFF0000 for this code.
- instead of doing copy_and_restart, your loader would look up the required chdk image (which would consist of the core and the restart code) and load that instead.
- you'd have to do a bit of shuffling to avoid over-writing yourself.

Another variation is possible, which might be more efficient:
- In each regular CHDK image, include the ID/loader code. If this is relatively small, it won't add much to load time, and it can be discarded before the CHDK fully boots, so it won't take away from available memory.
- The first thing each image checks is whether the correct platformid and version string are at the expected addresses for this camera.
- If those are correct, it boots the code that was already loaded with this diskboot.bin, essentially using the normal boot process.
- If it isn't correct, it tries to find the correct one on disk, and copy that to diskboot.bin.
- If it's hard to get write functions in the loader (quite possible, the functions used by udumper aren't suitable) you would instead load the image as described in the method above, but signal that it needs to do the copy. This could be done by modifying a variable in the loaded image. Once CHDK was booted, it would take care of the copy (although you'd have to work around the fact that we hide diskboot.bin under a dummy device driver in h_usrRoot.)

Don't forget what the H stands for.

*

Offline madcat

  • *
  • 9
  • ixus 860 black
Re: we already have universal dumper... why dont we have a universal loader?
« Reply #15 on: 30 / October / 2008, 18:08:34 »
reviving, had a chat in irc

Quote

...

[01:29:56] pixeldoc2000: maybe a nice setup or gui to choose and install chdk on the memory card would be a better "solution"
[01:30:28] pixeldoc2000: like to extend cardtricks...

...

Suggesting to keep things simple, maybe we can have a menu option in CHDK to replace diskboot.bin and other files (like config) from other dirs. Then shut down.. and move card to another cam, or just switch CHDK build or config...

Not sure if anyone suggested this before, but idea is flying in the air, sorry if repeating someone.
« Last Edit: 30 / October / 2008, 18:22:55 by madcat »

*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: we already have universal dumper... why dont we have a universal loader?
« Reply #16 on: 30 / October / 2008, 18:32:09 »
0000007: Jumping between chdk versions - CHDK Bugtracker :)
also in the same playground: 0000010: Format SD card in camera and retain CHDK on card - CHDK Bugtracker

dont feel sorry btw (well, you can make up for it by actually implementing some of this stuff :D) ;)

*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: we already have universal dumper... why dont we have a universal loader?
« Reply #17 on: 30 / October / 2008, 18:38:06 »
oh btw here is the original thread i created that was then transformed into the individual tickets in the bugtracker: for devs: vacant jobs, must-have features, status & overview / for users: a poll

(sorry for doublepost, just wanted to make sure u read this)


 

Related Topics