Op 8-9-2009 17:46, Kevin O'Connor schreef:
> I'm still around, but if you add me to the "To:" line, you'll get a
> faster response.
>    
Im not in a rush to get an answer, take your time :)
> $ cbfstool coreboot-qemu-freedos-20090818.bin print
> coreboot-qemu-freedos-20090818.bin: 512 kB, bootblocksize 65536, romsize 
> 524288, offset 0x0
> Alignment: 16 bytes
>    
I read about the tool, just don't got a Linux system. Guess that Linux 
Coreboot LiveCD will someday be around, hosting a live Linux, Coreboot 
environment, Flashrom and QEMU on it, so coreboot images can be created 
for both the actual system's BIOS, and for QEMU to allow experimentation 
first before applying same compile procedure to your motherboard. To 
have an entire Linux around just to remove/add components to a 512KB 
file sounds strange as well. Is the LZMA compression done by anything? 
Is 7-zip suitable?
> Name                           Offset     Type         Size
> normal/payload                 0x0        payload      30685
> normal/coreboot_ram            0x7810     stage        24867
> pci1013,00b8.rom.lzma          0xd970     optionrom    13047
> floppyimg/FreeDOS.lzma         0x10ca0    0x00000063   94961
>                                 0x27fd0    free         294936
>
> So, coreboot is taking up ~88K (the bootblock of 65536 plus 24867).
> This is a bit high and is probably due to padding - which the coreboot
> team has been working on recently.  In practice, I expect coreboot to
> be under 64K.
>
> SeaBIOS is the "normal/payload" file and consumes 30K (after lzma
> compression).  The vga option rom is taking 13K (after lzma).
>    
So 88+30+13 = 131KB, leaving around 125KB compressed space for a disk 
image on 256KB flash, and 381 on 512KB flash part. That gives me some 
nice goals to fill a FreeDOS image (with most programs not compressable, 
only FreeCOM/command.com had some text strings attached I think).
> Finally, the freedos floppy image takes 95K after lzma compression.
>    
And around 290KB available :)
> Your numbers look a little optimistic, but are roughly accurate.
>
>    
Knowing we use UPX on programs, so compression gain is about 0, I could 
make an estimate indeed.
So far I came up with the following (partially dutch description under 
Windows 7 apparently, by WinImage export facility):

AUTOEXEC.BAT    1.505    Windows-batchbestand  30-8-2009  17:47:10
COMMAND.COM    66.945    MS-DOS-toepassing     28-8-2006  19:39:14
DEVLOAD.COM     3.066    MS-DOS-toepassing     25-6-2008  21:18:16
fdapm.com       7.162    MS-DOS-toepassing     27-6-2007  1:44:38
FDISK.EXE      35.880    Toepassing            11-8-2006  14:57:46
FORMAT.EXE     30.686    Toepassing            13-7-2006  2:33:46
KERNEL.SYS     45.161    Systeembestand         1-8-2009  16:18:44
SHSUCDX.COM     8.083    MS-DOS-toepassing     1-10-2006  17:47:58
SYS.COM        11.447    MS-DOS-toepassing      1-8-2009  16:18:30
UIDE.SYS        6.433    Systeembestand        23-6-2009  11:00:00

My goal was to have working software in flash to allow disk 
partitioning. Devload loads .sys drivers from commandline, 
sushucdx/uide.sys for CD-ROM , fdapm for reboot/shutdown, 
fdisk/format/sys for partitioning, populating FAT filesystem and 
transferring system files.
Perhaps text editor and/or a memory manager would make sense.
> -Kevin
>    
Bernd

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to