You can change the ROM_SIZE in MB Option.lb to make final
Normal+Fallback size to 512K.
YH
________________________________
From: linuxbios-bounces(a)openbios.org
[mailto:linuxbios-bounces@openbios.org] On Behalf Of San Mehat
Sent: Friday, September 16, 2005 8:34 AM
To: LinuxBIOS
Subject: [LinuxBIOS] Building a viable rom *without* the fallback image
Hey all,
I'm trying to figure out how to do a build a rom which contains *only*
the normal image and not the fallback. For my purposes I don't believe I
need a fallback image since I'm burning my images to a ROM emulator. The
rom in question is only 512k and I need to fit 'other stuff' in there as
well.
Appreciate it :)
-San
Hey all,
I'm trying to figure out how to do a build a rom which contains *only* the
normal image and not the fallback. For my purposes I don't believe I need a
fallback image since I'm burning my images to a ROM emulator. The rom in
question is only 512k and I need to fit 'other stuff' in there as well.
Appreciate it :)
-San
I was looking at the PromJet over a year ago, it runs around $1,500 with
the LPC/FWH option.
They seem to nickle and dime you with this unit. Base price + LPC/FWH
support + 32PLCC adapter + ethernet (Parallel Port is standard).
http://www.emutec.com/pjetmain.html
Rod
>
>
> >Sorry, I should have googled more first. The manuals are at:
> >http://www.tech-tools.com/romtools.htm
>
> I looked at the FlexROM III, it appears to emulate just flat 8 or 16
> bit devices. PLCC's are more complicated, they frequently make use of
> an LPC interface that clocks in 4 bits of data at a time (as I recall)
> to get the address into the chip, then clocks out 4 bits of data at a
> time. I think an operation is 16 bits at a time. This is all
> transparent
> from the system's perspective. However behind the scenes it is a
> complicated dance.
>
> LPC = Low Pin Count
>
> -Dave
>
> --
> LinuxBIOS mailing list
> LinuxBIOS(a)openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
I have heard of using canned air to blow the solder out and crystallize
it, but I don't think I would try this. I use a heat gun and pair of IC
tweezers. Whatever you do, add some solder paste so it reflows first.
Ideally you should use a tip for the PLCC that concentrates the heat on
the legs of the chip and doesn't overheat the chip itself. Take a look
at the temp ratings of the chip if you use the heatgun approach. Most
chips are only rated to take that kind of heat a little longer than it
takes to reflow the solder.
-----Original Message-----
From: linuxbios-bounces(a)openbios.org
[mailto:linuxbios-bounces@openbios.org] On Behalf Of Steve Gehlbach
Sent: Thursday, September 15, 2005 11:41 AM
To: Guido Fiala
Cc: linuxbios(a)openbios.org
Subject: Re: [LinuxBIOS] PLCC removal trick
Guido Fiala wrote:
>On Wednesday 14 September 2005 21:56, Dave Ashley wrote:
>
>
>>I don't know about anyone else but the dental floss idea didn't work
>>at all for me, the floss interferes with the pins.
>>
>>I had this idea on how to remove the chip easily, but I haven't tried
>>it. Just get some strong epoxy and glue onto the top surface of the
>>flashrom something to act as a handle. After it's dry, use that to
>>pull the chip out.
>>
>>
>
>Instead of epoxy you might use hot-glue (or whats it called), or, even
>better, "Power Strip" - a removable 2-side-glue flexible tape...
>
>
>
>
It's a good idea, but keep in mind that some programmers (such as my
Needhams) have a cover that closes over the chip to program it, so a
removal knob might interfere with closing the cover. Maybe the
programmer will make contact anyway with the cover open, haven't tried
it so I don't know.
Steve
--
LinuxBIOS mailing list
LinuxBIOS(a)openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
>Sorry, I should have googled more first. The manuals are at:
>http://www.tech-tools.com/romtools.htm
I looked at the FlexROM III, it appears to emulate just flat 8 or 16
bit devices. PLCC's are more complicated, they frequently make use of
an LPC interface that clocks in 4 bits of data at a time (as I recall)
to get the address into the chip, then clocks out 4 bits of data at a
time. I think an operation is 16 bits at a time. This is all transparent
from the system's perspective. However behind the scenes it is a
complicated dance.
LPC = Low Pin Count
-Dave
>When I put this code in auto.c (V2) before the early_mtrr_init():
> __asm__ volatile (" invd");
I spoke too soon, the problem isn't fixed by just doing the invd.
-Dave
Jon McDowell wrote:
>I committed similar change for EPIA-M earlier today; I'm now getting a
I looked at V1 epia-m support and found there was a workaround:
/* new Via Edens seem to need an early invalidate - before enabling
* caches
*/
invd
When I put this code in auto.c (V2) before the early_mtrr_init():
__asm__ volatile (" invd");
all the strange behaviour goes away, and booting is fast again.
-Dave
Doug Bell was having trouble with serial out on epia-sp.
I tracked this problem to the cache. If the
early_mtrr_init() call isn't done, the problem goes
away. Within early_mtrr_init() if the call to
enable_cache() is commented out, the problem goes
away. Enabling the cache on the c3 Nehemia is
causing strange behaviour.
This mailing list is pretty much dead as regards
actual help, NXTV is working on epia-sp support
and we'll be contributing our results back to the
project. Some support would be in order. I/NXTV
contributed plenty years ago to the epia-m support
for V1, as many old timers will attest.
-Dave
