autoboot

[B. Cole]

> Until then, you can play with a bootable CF card now:
> http://magiclantern.wikia.com/wiki/Autoboot

Well I've tried, and it's not working. 
There are several things wrong with your web page description that threw me off for a bit.  I'm going to list the problems here so that others won't be thrown off as well:
1. You say "write the magic strings to the MBR of the CF card"
But the magic strings are actually written to the beginning of the first partition not the MBR; these are different disk sectors. (/dev/sdc1 not /dev/sdc for example).
2. The offsets you show are for FAT32 disks only (I have some fat16 CF cards from my older canon SLR that require the FAT16 offsets).  I know, any CF card used for video is likely to be >= 4GB and thus FAT32.
3. Your make-bootable script uses hex offsets for dd, but dd doesn't parse offsets in hex.  At least not any version of dd I've ever used.

Attached is a new version of make-bootable that can handle both fat16&fat32.

After the above corrections, I can make my 7D detect the boot disk.  By detect I mean the camera just halts trying to read the card instead of turning on normally.  The system seems to not run any autoexec.bat I've tested with.  I banged my head on this for a while before realizing this must just be because I don't have the diskboot flag set.

Yet I don't think I can set that flag without using a custom .fir file first.  So I don't get why you recommend the autoboot procedure as a starting point.

I'm thinking that in order to get the flag set to non-zero at 0xF800,0008 I have to hunt down the 7D address for the "call" function and invoke it with call("EnableBootDisk"), and wrap that all up into a custom .fir;  Or does that routine even work before dryos is running?

[Trammell Hudson]

On Sat, Mar 06, 2010 at 04:05:40PM -0800, B. Cole wrote:
> 1. You say "write the magic strings to the MBR of the CF card"
> But the magic strings are actually written to the beginning of the first
> partition not the MBR; these are different disk sectors. (/dev/sdc1 not
> /dev/sdc for example).

Ah, that is a good catch. Feel free to update the wiki (and we'll
need to update the menu item to say something other than "Write
MBR").

> 2. The offsets you show are for FAT32 disks only (I have some fat16 CF cards
> from my older canon SLR that require the FAT16 offsets). I know, any CF
> card used for video is likely to be >= 4GB and thus FAT32.

That's true. I don't have any FAT16 cards and didn't realize that
the 5D even supported them.

> 3. Your make-bootable script uses hex offsets for dd, but dd doesn't parse
> offsets in hex. At least not any version of dd I've ever used.

OS X handles them, which means that the BSD ones probably do, too.

> After the above corrections, I can make my 7D detect the boot disk. By
> detect I mean the camera just halts trying to read the card instead of
> turning on normally. The system seems to not run any autoexec.bat I've
> tested with.

The file must be called AUTOEXEC.BIN, not .bat.

> I banged my head on this for a while before realizing this
> must just be because I don't have the diskboot flag set.
>
> Yet I don't think I can set that flag without using a custom .fir file
> first. So I don't get why you recommend the autoboot procedure as a
> starting point.

The 7D dumping firmware that you ran also set the flag for you as a
side benefit. If the flag were not set, the camera would ignore the
bootable partition -- the fact that your camera hangs indicates that
it was attempting to find the autoboot binary.

> I'm thinking that in order to get the flag set to non-zero at 0xF800,0008 I
> have to hunt down the 7D address for the "call" function and invoke it with
> call("EnableBootDisk"), and wrap that all up into a custom .fir; Or does
> that routine even work before dryos is running?

In this case you must look for the function in the flasher binary,
not in the ROM dump since the dumper code is running the RAM image
of DryOS rather than the firmware version. According to my code it
is at:

void (*EnableBootDisk)(void) = (void*) 0x836978;

Attached is my incredibly hacked up, messy, and not ready for
prime-time 7D dumper.c program. From the number of "#if 0", you can
tell that this is a work-in-progress and I've been trying different
things.

--
Trammell

[B. Cole]

On Sun, Mar 7, 2010 at 9:00 AM, Trammell Hudson <hud...@osresearch.net> wrote:

> 3. Your make-bootable script uses hex offsets for dd, but dd doesn't parse
> offsets in hex.  At least not any version of dd I've ever used.

OS X handles them, which means that the BSD ones probably do, too.

 I checked the gnu coreutils source and the problem is dd treats 0x1234 as 0*1234=0.  There is no support for hex there.  See:

% dd if=/dev/zero count=0x10
0+0 records in
0+0 records out
0 bytes (0 B) copied, 7.344e-06 s, 0.0 kB/s
% dd if=/dev/zero count=2x10
20+0 records in
20+0 records out
10240 bytes (10 kB) copied, 0.000533406 s, 19.2 MB/s
%

I do see that OSX does parse the hex however.  So hex might work but
is not portable.

> After the above corrections, I can make my 7D detect the boot disk.  By
> detect I mean the camera just halts trying to read the card instead of
> turning on normally.  The system seems to not run any autoexec.bat I've
> tested with.

The file must be called AUTOEXEC.BIN, not .bat.

Er, yes of course, I was using AUTOEXEC.BIN in my tests, just typed the
wrong thing in email.

 

 

The 7D dumping firmware that you ran also set the flag for you as a
side benefit.  

Ah, how tricky of you :)
Thanks for the updated dumper snapshot.
Now I have a chance of some A/B comparisons between what is working and
what's not.  Guess I better take a closer look at the dumper code now.