Stefan Reinauer | 1 May 02:39 2006
Picon

Re: S2882 Video

* Ronald G Minnich <rminnich <at> lanl.gov> [060501 00:37]:
> >This is the code that prints the message in src/include/x86emu/x86emu.h
> >
> >#ifdef  DEBUG
> >#define HALT_SYS()      \
> >        printk("halt_sys: file %s, line %d\n", __FILE__, __LINE__); \
> >        X86EMU_halt_sys();
> >#else
> >#define HALT_SYS()      X86EMU_halt_sys()
> >#endif
> >
> >DEBUG is undefined in devices/emulator/x86emu/debug.h and never set in
> >the emulator files.. any idea why the message is printed at all? 
> 
> so we know that vga emulation terminated correctly ...

I agree that a message makes sense. I just wonder where DEBUG gest set
in this context. devices/emulator/x86emu/debug.h explicitly undefs DEBUG
so I'd assume the message would not be printed by default?!

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info <at> coresystems.de  • http://www.coresystems.de/

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
(Continue reading)

yhlu | 1 May 04:07 2006
Picon

Re: WORK! :) Power button question

your iasl seems too new...

YH

On 4/30/06, Hidasi Jozsef <hidi <at> e-tiger.net> wrote:
> Hi!
>
> /usr/sbin/iasl -tc /src/LinuxBIOSv2/src/mainboard/tyan/s2882/dx/pci2.asl
>
> Intel ACPI Component Architecture
> ASL Optimizing Compiler version 20060421 [Apr 30 2006]
> Copyright (C) 2000 - 2006 Intel Corporation
> Supports ACPI Specification Revision 3.0a
>
> Segmentation fault
>
>
> any suggestions?
>
>
>
> Sunday, April 30, 2006, 8:24:08 PM, you wrote:
>
> > what is your Linux dist...? If it is suse, you can install the package
> > from the source disk...
>
> > YH
>
>
>
(Continue reading)

Eric Poulsen | 1 May 04:52 2006

Re: Epia ML 5000 VGA (Again!) -- Moving backwards, somehow.

Daniel,

mainboard.c already looks like this in src/mainboard/via/epia-m.  It 
seems to take care of both the $3122 and $3123 devices.

There are other weird things happening.  LB _does not_ compile the way 
it used to out-of-the-box, even for older revisions.  It gives me 
linking errors every time I try to enable VGA 
(CONFIG_CONSOLE_VGA,CONFIG_PCI_ROM_RUN), unless I increase the 
ROM_IMAGE_SIZE, as recommended by Stefan.  I figured maybe my payload 
was too large and pushing the image > $10000, so I recompiled filo with 
a bunch fewer options, and it was only 26K (vs 39K before), and it still 
won't link without increasing ROM_IMAGE_SIZE to $12000.  I'm not sure if 
this is related, but it is weird.  Can ROM_IMAGE_SIZE be changed w/o 
changing any of the other parameters?

Also, does anyone have a good explaination of:

ROM_SIZE (Appears to be total size of your rom chip)
ROM_IMAGE_SIZE (Size of this rom image, fallback or normal),  defaults 
to $10000 (64K)
ROM_SECTION_OFFSET=0x10000 ???
ROM_SECTION_SIZE=0x30000 ??? ROM section == total used by LB minus VGA 
rom size???

void write_protect_vgabios(void)
{
  device_t dev;

  printk_info("write_protect_vgabios\n");
(Continue reading)

Ronald G Minnich | 1 May 05:46 2006

Re: Epia ML 5000 VGA (Again!) -- Moving backwards, somehow.

Eric Poulsen wrote:
> Daniel,
> 
> mainboard.c already looks like this in src/mainboard/via/epia-m.  It 
> seems to take care of both the $3122 and $3123 devices.
> 
> There are other weird things happening.  LB _does not_ compile the way 
> it used to out-of-the-box, even for older revisions.  It gives me 
> linking errors every time I try to enable VGA 
> (CONFIG_CONSOLE_VGA,CONFIG_PCI_ROM_RUN), unless I increase the 
> ROM_IMAGE_SIZE, as recommended by Stefan.  I figured maybe my payload 
> was too large and pushing the image > $10000, so I recompiled filo with 
> a bunch fewer options, and it was only 26K (vs 39K before), and it still 
> won't link without increasing ROM_IMAGE_SIZE to $12000.  I'm not sure if 
> this is related, but it is weird.  Can ROM_IMAGE_SIZE be changed w/o 
> changing any of the other parameters?
> 
> Also, does anyone have a good explaination of:
> 
> ROM_SIZE (Appears to be total size of your rom chip)
> ROM_IMAGE_SIZE (Size of this rom image, fallback or normal),  defaults 
> to $10000 (64K)
> ROM_SECTION_OFFSET=0x10000 ???
> ROM_SECTION_SIZE=0x30000 ??? ROM section == total used by LB minus VGA 
> rom size???

see my linux journal article on the web. I think that's where it is. 
There is a figure there that might clear it up.

Or I can send you the article directly.
(Continue reading)

Eric Poulsen | 1 May 06:36 2006

Ron's Linux Journal article

Found it, posting it to the list for the benefit of others:

"Porting LinuxBIOS to the AMD SC520: A Follow-up Report"
[This has the nifty diagram of how all the *_SIZE options work together]
http://www.linuxjournal.com/article/8310

"LinuxBIOS at Four"
http://www.linuxjournal.com/article/7170

Ronald G Minnich wrote:

>>
>> Also, does anyone have a good explaination of:
>>
>> ROM_SIZE (Appears to be total size of your rom chip)
>> ROM_IMAGE_SIZE (Size of this rom image, fallback or normal),  
>> defaults to $10000 (64K)
>> ROM_SECTION_OFFSET=0x10000 ???
>> ROM_SECTION_SIZE=0x30000 ??? ROM section == total used by LB minus 
>> VGA rom size???
>
>
> see my linux journal article on the web. I think that's where it is. 
> There is a figure there that might clear it up.
>
> Or I can send you the article directly.
>
> ron
>

(Continue reading)

Eric Poulsen | 1 May 06:45 2006

Solved: Makefile weirdness (was: Epia ML 5000 VGA (Again!) -- Moving backwards, somehow.)

Okay, I got it to work again.  This is weird, but I figured out what the
issue is.  I think the build system for LB (at least for the Epia-M
branch) is bad.  I don't have any experience with romcc or building
BIOSes, but I do have quite a bit of experience with C,C++, and using
makefiles -- something seems very wrong here, especially when you look
at the details of the two build processes shown below.  IMHO, "make
clean" should set you back to the beginning (as it seems to),  and a
compile after that should fix any weirdnesses with linking.

Just in case it's not clear, in both examples below, there are NO "real"
code changes between them, only configuration changes.  Also, this is
with my own Epia-ML branch (derived from Epia-M) -- the only difference
is that I removed the ieee1394 init code in auto.c and edited the
Config.lb for the mainboard so that it doesn't init the floppy and the
CF card reader, which don't exist on the ML.  I was having the exact
same issues with the out-of-the-box Epia-M branch. When I built it (both
Epia-M and Epia-ML branches) successfully in the past, I _never_ used
make clean because I figured buildtarget would fix any issues,
especially since a 'make' after 'buildtarget' resulted in recompilation
of several files.

In short, my recent use of 'make clean' seems to be hosing the process.

This _DOES NOT WORK_ (but it should):

(pseudocode -- not literal)
]Set CONFIG_CONSOLE_VGA=1, CONFIG_PCI_ROM_RUN=1 in Config.lb
]buildtarget via/epia-m
]cd via/epia-m/epia-m
]make clean
(Continue reading)

Christian Sühs | 1 May 11:13 2006
Picon

Re: MB1030 / 3036 VGA comes up :D


>>
>> Yeah, but I can't get a point to start :D I'm not sure what we need.
> 
> 
> Now you know why I haven't done it yet.  Its a little more than just a
> diff of the trees.

;)

> 
>> The inTree stuff based on X.org?
> 
> 
> The in-tree stuf is based on the ./util/vgabios stuff which came from
> xfree86 long ago.  The X.org fork should not be that much different
> than the xfree86 stuff.  The stuff in-tree has the directory structure
> cleaned up so its more sane.

Yeah, the X.org version based on an older xfree86 one.

> 
> Rather than diff the in-tree to the X.org or xfree86 I would start by
> diffing the stuff in util/vgabios/x86emu first.  That will let you see
> what has been introduced into the X* stuff.  I would then fork a copy
> of vgabios and test all the updates.  Then when you understand what
> changes were made you can try to roll them into the in-tree.

I was a little confused about some functions, which are not declared in 
the header files and also not present in the orginal :D
(Continue reading)

Christian Sühs | 1 May 12:23 2006
Picon

Re: MB1030 / 3036 VGA comes up :D


> 
> Chris, please disable all your current emu debug stuff and then apply
> this patch and send the output.
> This should show the timer IO accesses but not  all the other stuff to
> keep the noise level down
> .

Sorry, but there is no more output with the applied patch.

chris

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Christian Sühs | 1 May 13:21 2006
Picon

Re: MB1030 / 3036 VGA comes up :D

Christian Sühs schrieb:
>>Chris, please disable all your current emu debug stuff and then apply
>>this patch and send the output.
>>This should show the timer IO accesses but not  all the other stuff to
>>keep the noise level down
>>.
> 
> 
> Sorry, but there is no more output with the applied patch.
> 
> chris
> 

I have forgotten to post the results for changing BC_XMAP_1 values.

BC_XMAP_2 / 3 are set to 0x77777777

first I have tried the AMD preffered values:
The emulatur is entered, machine seems to hang. There is no more output 
after entering.

After that I have enabled the whole video RAM section A0000 - BFFFF as 
read/write/cache 0x07070067:
I have also the long delay by vga initializing, but after upcoming there 
are only unreadable characters on the screen.

Now I also think, that there is a problem with the emu and my board.

chris

(Continue reading)

Hidasi Jozsef | 1 May 12:36 2006
Picon

Slow kernel loading?

 Hi List!

 Yesterday I've manged some kind of ACPI into my S2882 after iasl
 segmentation faults I've dumped the original DSTC ant it compiles
 cleanly for now. BUT, is it normal when I load a kernel via network
 the decompression takes about minutes? So etherboot says Done and I
 have to wait a lot to boot the kernel, THERE'S NO OUTPUT AT ALL TILL
 THAT!

-- 
Best regards,
 Hidasi                          mailto:hidi <at> e-tiger.net
--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Gmane