Jump to content











Photo
- - - - -

being a technerd....


  • Please log in to reply
11 replies to this topic

#1 lianzi2000

lianzi2000

    Member

  • Members
  • 43 posts
  •  
    United States

Posted 08 June 2008 - 05:23 AM

I am n00b in RAM boot technology, I have spent quite sometime try to understand how sdi technology works.....

according to M$DN document(s), the whole sdi image is somehow loaded into memory and the BOOT blob is put at real-mode address 0000:7c00. This is quite legendary and straight-forward. I'm lost after that. what exactly does the boot blob do? Logically I would assume it acts like a MBR of a harddrive and load the LOAD blob, which is basically ntldr (or could it be setupldr?...).

if my guess is right, it is just a mimic of normal booting from HD, then the ntldr should be looking for the system on a device -- here obviouly the ramdisk. When did the ramdisk driver installed? by BOOT blob?

Another question is, when ntldr mounted the PART blob as a ramdisk, which obviously is not the system itself (the whole boot.sdi is only like 3MB). How is the boot.wim "attached" to the sdi image? and what exactly does "attach" mean here?

Thanks all in advance! I am seeking as many details as possible, but any enlightenment is appreciated.

lianzi2000

#2 wendy

wendy

    Frequent Member

  • Lady
  • 279 posts
  • Location:one mile from the QR main line
  • Interests:Operating systems, Weights and Measures, Geometry
  •  
    Australia

Posted 08 June 2008 - 07:32 AM

The SDI kit is a large file, akin to say, ibmbio.sys

It is loaded at 07c00 because that is the position that the chip expects to find boot code.

Once it is loaded, it creates a ramdisk cdrom, and unpacks boot.wim into it. The ramdisk is held in memory and the keys are passed through to the ramdisk driver. The image is then started. Specifically, control is passed to the nt kernel (ntoskrnl.exe), and it takes over loading things. The edi code is then dropped from memory.

SDI loaders are used in some other archetures.

W

#3 was_jaclaz

was_jaclaz

    Finder

  • Advanced user
  • 7100 posts
  • Location:Gone in the mist
  •  
    Italy

Posted 09 June 2008 - 03:17 PM

A good place to start:
http://www.boot-land...?...ic=4882&hl=

jaclaz

#4 lianzi2000

lianzi2000

    Member

  • Members
  • 43 posts
  •  
    United States

Posted 09 June 2008 - 05:15 PM

A good place to start:
http://www.boot-land...?...ic=4882&hl=

jaclaz


Excellent! thank you very much!

Lianzi2000

#5 lianzi2000

lianzi2000

    Member

  • Members
  • 43 posts
  •  
    United States

Posted 11 June 2008 - 12:45 AM

Excellent! thank you very much!

Lianzi2000



ok, I have browsed through the book and everything it recommended. I felt, for a short moment, that I thought everything through, but when I started to do some peek into the boot.sdi comes with vista installation disk, I got more confused.

first, sdimgr boot.sdi showed this:


=============================================
SDI File Manager version 1.00.621
Copyright © 1999-2001 Microsoft Corp. All Rights Reserved.

SDI File : D:\Home\Projects\sdiboot\boot.sdi
MDB Type : ---
Boot Code Offset : 0x00000000.00000000
Boot Code Size : 0x00000000.00000000
Vendor ID : 0x0000 (0)
Device ID : 0x0000 (0)
Device Model : {00000000-0000-0000-0000-000000000000}
Device Role : 0
Runtime GUID : {00000000-0000-0000-0000-000000000000}
Runtime OEM Rev : 0
Page Alignment : 2 (8192 bytes)

Type Offset Size Base Address Attr
---- ------------------- ------------------- ------------------- ----------
PART 0x00000000.00002000 0x00000000.00303C00 0x00000000.00000007 0x00000000
WIM 0x00000000.00306000 0x00000000.00000000 0x00000000.00000000 0x00000000
============================================================

There is no BOOT or LOAD blobs!




then I tried sdimgr /export:WIM,wim.bin, not working, said "Error 9009 (0x2331) in "CmdExport": Invalid blob type: "WIM"

sdimgr /writepart:N: works, but after that the N: only showed a hidden folder "System Volume Information", nothing else. disk property window however indicated the correct size occupied by the partition.


I'm totally lost. What is in that part blob? what is the function of that part? if I want to boot sex.wim instead of boot.wim, where should I modify and how?

Thank you very much!


lianzi2000

#6 Biatu

Biatu

    Member

  • Members
  • 69 posts
  •  
    United Kingdom

Posted 4 weeks ago

Sorry for the necro-post, however I am attempting to create a new boot.sdi with say 2GB of space. Is that even possible?



#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15190 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 4 weeks ago

Sorry for the necro-post, however I am attempting to create a new boot.sdi with say 2GB of space. Is that even possible?

With all due respect :), why?

 

Link to the reboot.pro discussion (links here are for the old bootland server):

http://reboot.pro/to...hat-is-bootsdi/

 

In the "new" BOOTSDI approach (Vista and later) the actual sdi file is only a "mountpoint", and as such all attempts have been about making it smaller (or as small as possible).

 

In the "old" BOOTSDI approach (up to Server 2003) it is a boot image by any other name, and AFAICR has a lot of complexities/limitations that other, newer "booting from image" approaches do not have (ot that have been ironed down).

 

The reference thread for the latter is:

http://reboot.pro/to...reator-utility/

 

:duff:

Wonko



#8 Biatu

Biatu

    Member

  • Members
  • 69 posts
  •  
    United Kingdom

Posted 4 weeks ago

Well the theory was to avoid using FBWF, so after hours of trial and error I ended up using HxD and dumping the PART of the sdi, expanding it, then updating the offsets in the TOC. I got WinPE to boot and also had to update the Ramdisk size in the BCD. Anyway WinPW just complained that the disk was write protected.

The reasons for this attempt were 1) Be able to mount a wim in the ramdisk without having to apply it. 2) hardlink support. 3) use different sized boot.sdi for use on systems with different amounts of free memory



#9 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15190 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 4 weeks ago

Well the theory was to avoid using FBWF, so after hours of trial and error I ended up using HxD and dumping the PART of the sdi, expanding it, then updating the offsets in the TOC. I got WinPE to boot and also had to update the Ramdisk size in the BCD. Anyway WinPW just complained that the disk was write protected.

The reasons for this attempt were 1) Be able to mount a wim in the ramdisk without having to apply it. 2) hardlink support. 3) use different sized boot.sdi for use on systems with different amounts of free memory

If you are happy with it, that is fine :), but your explanation is not clear (to me) at all. :(

 

I am not even sure why you would want to use FBWF at all, then, since you talk of BCD and WIM, very likely you are using the kind where the boot.sdi is only used normally as a mountpoint :dubbio:

 

No Idea what WinPW is.

 

:duff:

Wonko



#10 ambralivio

ambralivio

    Frequent Member

  • Advanced user
  • 194 posts
  •  
    Italy

Posted 4 weeks ago

No Idea what WinPW is.

 

:duff:

Wonko

He/She wrongly pushed the W key instead of E one (very near on the keyboard), I suppose



#11 Biatu

Biatu

    Member

  • Members
  • 69 posts
  •  
    United Kingdom

Posted 3 weeks ago

Yes I mean't winPE, sorry. To clarify I was saying, I wanted to use a larger boot.sdi as a ramdisk instead of FBWF to allow for more features like mounting a WIM to the ramdisk. But unfortunately this failed as windows write protects the ramdisk.



#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15190 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 3 weeks ago

Yes I mean't winPE, sorry. To clarify I was saying, I wanted to use a larger boot.sdi as a ramdisk instead of FBWF to allow for more features like mounting a WIM to the ramdisk. But unfortunately this failed as windows write protects the ramdisk.

Sure :), but it is not like repeating that you want a larger boot.sdi instead of FBWF clarifies anything.

 

Maybe you want to explain (possibly starting a new thread) what are the reasons why you want to do that or more generally what is the goal.

 

The part about "using HxD and dumping the PART of the sdi, expanding it, then updating the offsets in the TOC" I don't understand without context/details, maybe it is just a matter of different tetminology used, do you mean that you created a larger boot.sdi image and hex edited contents of its 8192 byte header?

I.e. somehow manually do what the SDI Manager used to do:

https://docs.microso...=winembedded.5)

 

BTW, I just noticed that Ispy's nice document was MIA, re-uploaded it:

http://reboot.pro/to...hat-is-bootsdi/

 

If this is the case, whatever information you gathered in the process about the format of this header might be useful as it is AFAIK/AFAICR very little (if at all) documented, apart from:

https://web.archive....mbedded.5).aspx

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users