There was a time, quite some time ago, when somebody was booting
vxworks from linuxbios, i.e. it was the payload.
ron
On Thu, May 22, 2014 at 6:55 AM, Stojsavljevic, Zoran
<zoran.stojsavljevic(a)intel.com> wrote:
> Hello Peter,
>
> I'll try to find answers to these questions. I might even myself build one of these images to try such a creation on IVB EL2.
>
> Please, stay tuned.
>
> Best Regards,
> Zoran
>
> -----Original Message-----
> From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge
> Sent: Thursday, May 22, 2014 3:31 PM
> To: coreboot(a)coreboot.org
> Subject: Re: [coreboot] booting vxworks from linux BIOS
>
> Stojsavljevic, Zoran wrote:
>> There is possibility (my best guess) to use VxWorks as coreboot’s
>> payload, instead seabios
> ..
>> I can also investigate about booting VxWorks, if required
>
> It would be helpful to know how tightly the VxWorks kernel is tied to legacy runtime services from x86 BIOS and/or UEFI.
>
> If the VxWorks kernel is an ELF binary or similar simple binary format without very strong ties to legacy runtime services then it would most likely be straightforward to use a VxWorks kernel as payload with coreboot.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
> Intel GmbH
> Dornacher Strasse 1
> 85622 Feldkirchen/Muenchen, Deutschland
> Sitz der Gesellschaft: Feldkirchen bei Muenchen
> Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
> Registergericht: Muenchen HRB 47456
> Ust.-IdNr./VAT Registration No.: DE129385895
> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
Stojsavljevic, Zoran wrote:
> There is possibility (my best guess) to use VxWorks as coreboot’s
> payload, instead seabios
..
> I can also investigate about booting VxWorks, if required
It would be helpful to know how tightly the VxWorks kernel is tied to
legacy runtime services from x86 BIOS and/or UEFI.
If the VxWorks kernel is an ELF binary or similar simple binary
format without very strong ties to legacy runtime services then
it would most likely be straightforward to use a VxWorks kernel
as payload with coreboot.
//Peter
I've tried your suggestion. Building binutils on my 64-bit Fedora 20 system:
../../../binutils-2.23.2/bfd/doc/bfd.texinfo:325: unknown command `colophon'
../../../binutils-2.23.2/bfd/doc/bfd.texinfo:336: unknown command `cygnus'
make[3]: *** [bfd.info] Error 1
I have texinfo-5.1-4.fc20.x86_64 installed.
On 05/22/2014 02:42 AM, David Hendricks wrote:
> On Tue, May 20, 2014 at 8:51 PM, Sean McNeil <seanmcneil3(a)gmail.com
> <mailto:seanmcneil3@gmail.com>> wrote:
>
> Are you bullding on 64-bit machine and have:
>
>
> CONFIG_COMPILER_GCC=y
> CONFIG_ANY_TOOLCHAIN=y
>
> ?
>
>
> CONFIG_ANY_TOOLCHAIN should not be used in most cases. What does your
> .xcompile file look like?
>
> I'm building on a 64-bit host using the crossgcc toolchain. Try
> running the buildgcc script in util/crossgcc, then rm -f .xcompile and
> run make and see if that helps.
>
> For reference, here are my .xcompile and .config files as well as the
> output from make.
>
> xcompile.txt
> <https://docs.google.com/a/google.com/file/d/0BwyScGuaZ2uNLVhwSHh4V0VWY28/ed…>
>
> config.txt
> <https://docs.google.com/a/google.com/file/d/0BwyScGuaZ2uNZ2hEcENPQ2kwSHM/ed…>
>
> make.txt
> <https://docs.google.com/a/google.com/file/d/0BwyScGuaZ2uNY1phV0c4c0MtM0U/ed…>
>
>
>
> arch/x86/exec.S:1:0: note: this is the location of the previous
> definition
> /*
> ^
> arch/x86/exec.S: Assembler messages:
> arch/x86/exec.S:43: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:45: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:52: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:53: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:54: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:61: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:62: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:70: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:73: Error: operand type mismatch for `call'
> arch/x86/exec.S:81: Error: invalid instruction suffix for `pop'
> arch/x86/exec.S:91: Error: invalid instruction suffix for `pop'
> arch/x86/exec.S:92: Error: invalid instruction suffix for `pop'
> arch/x86/exec.S:93: Error: invalid instruction suffix for `pop'
> arch/x86/exec.S:97: Error: invalid instruction suffix for `pop'
> make[2]: *** [build/arch/x86/exec.libc.o] Error 1
> make[1]: *** [libpayload] Error 2
> make: *** [filo] Error 2
>
>
>
> On 05/21/2014 10:36 AM, David Hendricks wrote:
>> On Tue, May 20, 2014 at 6:31 PM, Sean McNeil
>> <seanmcneil3(a)gmail.com <mailto:seanmcneil3@gmail.com>> wrote:
>>
>> All the recent changes to how the compiler is defined have
>> now caused payloads like FILO and SeaBIOS to not build on
>> X86_64 machines. Is anyone working to fix this?
>>
>>
>> I just tried building images with each of those as payloads and
>> they seemed to compile fine for me. Try "rm -f .xcompile" before
>> compiling and see if that helps.
>>
>> If that doesn't work, can you post more details such as the git
>> version you're on and output of "make" ?
>>
>> --
>> David Hendricks (dhendrix)
>> Systems Software Engineer, Google Inc.
>
>
>
>
> --
> David Hendricks (dhendrix)
> Systems Software Engineer, Google Inc.
Hello Chinnu,
The best will be to use the latest coreboot git snapshot (if you use all other architectures except IA, then it is a bit trickier) with latest seabios as payload (all used with git clone <source tree>). Then you’ll need to boot to GRUB 2.00. which has (if I am not mistaken) multiboot command for booting non linux environment (GRUB 2.00 manual): http://www.gnu.org/software/grub/manual/grub.html
You might want to first boot to Linux from GRUB 2.00, and then install VxWorks image somewhere under Linux, initially installed with GRUB (you can go with some off the self distros: Ubuntu, or openSUSE, Fedora, Centos, U name it)!
There is possibility (my best guess) to use VxWorks as coreboot’s payload, instead seabios, but for this kind of “beauty” I prefer to kindly ask Patrick (Georgi), or maybe Stefan (Reinauer), or somebody else who is much more knowledgeable then me about coreboot itself, me - one small IA oriented person. ;-)
Hope this helps, at least to initiate some discussions (I can also investigate about booting VxWorks, if required, since VxWorks is Wind River leading product, and WR is bought… Rest are dots connected on unwritten. ;-) ).
Best Regards,
Zoran
From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Bhavana Chinnu
Sent: Wednesday, May 21, 2014 12:04 PM
To: coreboot(a)coreboot.org
Subject: [coreboot] booting vxworks from linux BIOS
hi...
can any one tell how to load coreboot with VxWorks
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
OK, so what you are saying is that CONFIG_ANY_TOOLCHAIN is obsolete and
no longer supported. Can it be removed from coreboot then?
Cheers,
Sean
On 05/22/2014 02:42 AM, David Hendricks wrote:
> On Tue, May 20, 2014 at 8:51 PM, Sean McNeil <seanmcneil3(a)gmail.com
> <mailto:seanmcneil3@gmail.com>> wrote:
>
> Are you bullding on 64-bit machine and have:
>
>
> CONFIG_COMPILER_GCC=y
> CONFIG_ANY_TOOLCHAIN=y
>
> ?
>
>
> CONFIG_ANY_TOOLCHAIN should not be used in most cases. What does your
> .xcompile file look like?
>
> I'm building on a 64-bit host using the crossgcc toolchain. Try
> running the buildgcc script in util/crossgcc, then rm -f .xcompile and
> run make and see if that helps.
>
> For reference, here are my .xcompile and .config files as well as the
> output from make.
>
> xcompile.txt
> <https://docs.google.com/a/google.com/file/d/0BwyScGuaZ2uNLVhwSHh4V0VWY28/ed…>
>
> config.txt
> <https://docs.google.com/a/google.com/file/d/0BwyScGuaZ2uNZ2hEcENPQ2kwSHM/ed…>
>
> make.txt
> <https://docs.google.com/a/google.com/file/d/0BwyScGuaZ2uNY1phV0c4c0MtM0U/ed…>
>
>
>
> arch/x86/exec.S:1:0: note: this is the location of the previous
> definition
> /*
> ^
> arch/x86/exec.S: Assembler messages:
> arch/x86/exec.S:43: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:45: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:52: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:53: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:54: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:61: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:62: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:70: Error: invalid instruction suffix for `push'
> arch/x86/exec.S:73: Error: operand type mismatch for `call'
> arch/x86/exec.S:81: Error: invalid instruction suffix for `pop'
> arch/x86/exec.S:91: Error: invalid instruction suffix for `pop'
> arch/x86/exec.S:92: Error: invalid instruction suffix for `pop'
> arch/x86/exec.S:93: Error: invalid instruction suffix for `pop'
> arch/x86/exec.S:97: Error: invalid instruction suffix for `pop'
> make[2]: *** [build/arch/x86/exec.libc.o] Error 1
> make[1]: *** [libpayload] Error 2
> make: *** [filo] Error 2
>
>
>
> On 05/21/2014 10:36 AM, David Hendricks wrote:
>> On Tue, May 20, 2014 at 6:31 PM, Sean McNeil
>> <seanmcneil3(a)gmail.com <mailto:seanmcneil3@gmail.com>> wrote:
>>
>> All the recent changes to how the compiler is defined have
>> now caused payloads like FILO and SeaBIOS to not build on
>> X86_64 machines. Is anyone working to fix this?
>>
>>
>> I just tried building images with each of those as payloads and
>> they seemed to compile fine for me. Try "rm -f .xcompile" before
>> compiling and see if that helps.
>>
>> If that doesn't work, can you post more details such as the git
>> version you're on and output of "make" ?
>>
>> --
>> David Hendricks (dhendrix)
>> Systems Software Engineer, Google Inc.
>
>
>
>
> --
> David Hendricks (dhendrix)
> Systems Software Engineer, Google Inc.
All the recent changes to how the compiler is defined have now caused
payloads like FILO and SeaBIOS to not build on X86_64 machines. Is
anyone working to fix this?
Cheers,
Sean
Are you bullding on 64-bit machine and have:
CONFIG_COMPILER_GCC=y
CONFIG_ANY_TOOLCHAIN=y
?
arch/x86/exec.S:1:0: note: this is the location of the previous definition
/*
^
arch/x86/exec.S: Assembler messages:
arch/x86/exec.S:43: Error: invalid instruction suffix for `push'
arch/x86/exec.S:45: Error: invalid instruction suffix for `push'
arch/x86/exec.S:52: Error: invalid instruction suffix for `push'
arch/x86/exec.S:53: Error: invalid instruction suffix for `push'
arch/x86/exec.S:54: Error: invalid instruction suffix for `push'
arch/x86/exec.S:61: Error: invalid instruction suffix for `push'
arch/x86/exec.S:62: Error: invalid instruction suffix for `push'
arch/x86/exec.S:70: Error: invalid instruction suffix for `push'
arch/x86/exec.S:73: Error: operand type mismatch for `call'
arch/x86/exec.S:81: Error: invalid instruction suffix for `pop'
arch/x86/exec.S:91: Error: invalid instruction suffix for `pop'
arch/x86/exec.S:92: Error: invalid instruction suffix for `pop'
arch/x86/exec.S:93: Error: invalid instruction suffix for `pop'
arch/x86/exec.S:97: Error: invalid instruction suffix for `pop'
make[2]: *** [build/arch/x86/exec.libc.o] Error 1
make[1]: *** [libpayload] Error 2
make: *** [filo] Error 2
On 05/21/2014 10:36 AM, David Hendricks wrote:
> On Tue, May 20, 2014 at 6:31 PM, Sean McNeil <seanmcneil3(a)gmail.com
> <mailto:seanmcneil3@gmail.com>> wrote:
>
> All the recent changes to how the compiler is defined have now
> caused payloads like FILO and SeaBIOS to not build on X86_64
> machines. Is anyone working to fix this?
>
>
> I just tried building images with each of those as payloads and they
> seemed to compile fine for me. Try "rm -f .xcompile" before compiling
> and see if that helps.
>
> If that doesn't work, can you post more details such as the git
> version you're on and output of "make" ?
>
> --
> David Hendricks (dhendrix)
> Systems Software Engineer, Google Inc.
[-flashrom, +coreboot]
On Tue, May 20, 2014 at 5:06 AM, Mike Hibbett <mhibbett(a)ircona.com> wrote:
> I spotted these two in yesterday’s code base. I’m not likely to commit
> code anytime soon so I will leave it to someone else to pick up if they are
> interested.
>
>
>
> src/vendorcode/intel/fsp/baytrail/include/fspplatform.h:78
>
>
>
> Duplicate declaration of GetFspReservedMemoryFromGuid
>
>
>
> src/northbridge/intel/fsp_sandybridge/fsp/chipset_fsp_util.c:92
>
>
>
> GetUpdDefaultFromFsp (fsp_ptr,
> fsp_upd_data);/home/martin/extra/git/coreboot
>
>
>
>
>
> Maybe martin would like to fix that one :o)
>
Yeah, looks like some simple errors. May as well just send him a patch:
http://review.coreboot.org/#/c/5798/
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
