From: Tony Questad <tony.questad@datalight.com>
To: <mtd@infradead.org>
Subject: re[2]: SBC-MediaGX
Date: Fri, 29 Sep 2000 10:47:01 -0700 [thread overview]
Message-ID: <200009291744.KAA05725@firegate.datalight.com> (raw)
>> My understanding (you better check this before trying anything) is that
>> the BIOS extension only contains the VBF code needed for DOS to see the VBF
>> volume. If you trash it, all that will happen is that you won't be able to
>> access the VBF volume, and you can always reinstall it from the Arcom
>> floppy. The BIOS itself is in another flash chip entirely. I think.
That sounds right -- on the MediaGX the BIOS is contained in a seperate BIOS ROM, and the FlashFX BIOS Extension is stored in the beginning of the flash array. Erasing this will remove the FlashFX driver, but if this is not a concern at this time, you can always reprogram it from the original Arcom disks.
>> >Another question: why is the BIOS extension area soo big as
>> >the extension itself is only about 14kB? The autoexec.bat file
>> >on the Arcom bootfloppy mentions that the extension was enlarged
>> >some time ago to 256KB in order to accomodate the Windows CE
>> >registry???
>> Don't know. I stuck with 256kB on my board for the same reason you did. I
>> don't think it's critical; what's the maximum size for a ROM extension?
>> 16kB? 32kB?
What is the erase zone size on that board? You would need to reserve space in erase zone sized chunks; On a flash part with 128KB erase zones, the minimum you would need to reserve would be 128KB, no matter how large your BIOS extensions are. You do not want the area that your BIOS extension is in being moved around by FlashFX, or any wear leveling system as it would need to stay put in the beginning of the flash -- The reason for 256k escapes me at this moment, as I remember that the BIOS Extension for FlashFx is probably 16kb, but I am sure they were using the other area for CE related issues. It may very well be that the first 128k (or 64k) was reserved as a full sector to handle the 16kb BIOS extension, and the rest was done for future growth.
****************************************************************************
Senior Development Support Engineer Datalight, Inc
tel: 425 951 8086 x142 21520 30th Drive SE, Suite 110
fax: 425 951 8094 Bothell, WA
email: tony.questad@datalight.com 98021
Leverage over 100 man-years of embedded system experience! 24-hour/7-day
support is found at: http://datalight.custhelp.com/cgi-bin/datalight
****************************************************************************
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
next reply other threads:[~2000-09-29 17:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-09-29 17:47 Tony Questad [this message]
2000-09-30 11:19 ` SBC-MediaGX Alex J Lennon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200009291744.KAA05725@firegate.datalight.com \
--to=tony.questad@datalight.com \
--cc=mtd@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox