SeaBIOS December 2015

seabios@seabios.org

20 participants
68 discussions

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor 04 Dec '15

04 Dec '15

On Fri, Dec 04, 2015 at 07:08:50PM +0000, edward wandasiewicz wrote: > On 4 Dec 2015 7:04 p.m., "Kevin O'Connor" <kevin(a)koconnor.net> wrote: > > > > On Fri, Dec 04, 2015 at 06:36:18PM +0000, edward wandasiewicz wrote: > > > @ John > > > > > > Is the work on SeaVGABIOS for CBFS work under construction for the > > > Broadwell based Pixel 2015? > > > > > > Looking at Kevin's chromeimage.sh - showing relevant parts only > > > > > > CBFSTOOL=cbfstool > > > PAYLOAD=out/bios.bin.elf > > > PAYLOADVGA=out/vgabios.bin > > [...] > > > # > > > # Add SeaVGABIOS to CBFS > > > # > > > $ CBFSTOOL $CBFSFILE add -f $PAYLOADVGA -n vgaroms/seavgabios.rom -t > optionrom > > > > > > Question - if it is work under construction, the above may or may not > > > show any VGA output? i.e. black screen > > > > > > Or give it a whirl, and I may surprise myself? > > > > > > Or stick with > > > > > > ## Extract vgabios from SeaBIOS CBFS area of original image. > > > > > > ORIGCBFSFILE=orig-seabios.cbfs > > > > > > $ dd if=$ORIGIMAGE of=$ORIGCBFSFILE skip=2 bs=2M count=1 2> /dev/null > > > > > > $ CBFSTOOL $ORIGCBFSFILE extract -n pci8086,0406.rom -f pci8086,0406.rom > > > > > > $ CBFSTOOL $CBFSFILE add -f pci8086,0406.rom -n pci8086,0a06.rom -t > optionrom > > > > The logs you sent me seemed to indicate that SeaVGABIOS was running, > > This means use vgaroms/seavgabios.rom > > and leave commented parts in a commented state - no need for > pci8086,0a06.rom parts Yes. -Kevin

2 1

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor 04 Dec '15

04 Dec '15

On Fri, Dec 04, 2015 at 06:36:18PM +0000, edward wandasiewicz wrote: > @ John > > Is the work on SeaVGABIOS for CBFS work under construction for the > Broadwell based Pixel 2015? > > Looking at Kevin's chromeimage.sh - showing relevant parts only > > CBFSTOOL=cbfstool > PAYLOAD=out/bios.bin.elf > PAYLOADVGA=out/vgabios.bin [...] > # > # Add SeaVGABIOS to CBFS > # > $ CBFSTOOL $CBFSFILE add -f $PAYLOADVGA -n vgaroms/seavgabios.rom -t optionrom > > Question - if it is work under construction, the above may or may not > show any VGA output? i.e. black screen > > Or give it a whirl, and I may surprise myself? > > Or stick with > > ## Extract vgabios from SeaBIOS CBFS area of original image. > > ORIGCBFSFILE=orig-seabios.cbfs > > $ dd if=$ORIGIMAGE of=$ORIGCBFSFILE skip=2 bs=2M count=1 2> /dev/null > > $ CBFSTOOL $ORIGCBFSFILE extract -n pci8086,0406.rom -f pci8086,0406.rom > > $ CBFSTOOL $CBFSFILE add -f pci8086,0406.rom -n pci8086,0a06.rom -t optionrom The logs you sent me seemed to indicate that SeaVGABIOS was running, and thus you should use the steps above. -Kevin

2 1

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor 04 Dec '15

04 Dec '15

On Fri, Dec 04, 2015 at 05:50:29PM +0000, edward wandasiewicz wrote: > Looking at the output from Googles ChromeOS shell-ball, I do: > > Write the hardware ID to get future ChromeOS updates > > $ ./gbb_utility --set --hwid="SAMUS XXX-YYY-ZZZ" bios.bin bios.hwid.bin > > # dd out 2 megs of the ROM at 4 megs in > > $ dd bs=1M skip=4 count=2 if=bios.hwid.bin of=rwlegacy.cbfs > > Using the flashrom from John's site as upstream doesn't know anything about > flashmap. > > $ wget https://johnlewis.ie/Chromebook-ROMs/utils/flashrom -O > flashrom.jlewis > > $ sudo ./flashrom.jlewis -w -i RW_LEGACY:rwlegacy.cbfs > > Looking at your script, ORIGIMAGE is my bios.hwid.bin > > Do I run flashrom from the shell-ball > > $ sudo flashrom -w ./newimage.rom -i RW_LEGACY > > Or John Lewis flashrom > > $ sudo flashrom.jlewis.version -w ./newimage.rom -i RW_LEGACY I would guess that either would work. Upstream flashrom is likely not going to work (if it doesn't support flashmap). As long as the flashrom does support flashmap, then it should work. (No guarantees.) -Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by edward wandasiewicz 04 Dec '15

04 Dec '15

@ John Is the work on SeaVGABIOS for CBFS work under construction for the Broadwell based Pixel 2015? Looking at Kevin's chromeimage.sh - showing relevant parts only CBFSTOOL=cbfstool PAYLOAD=out/bios.bin.elf PAYLOADVGA=out/vgabios.bin # # Build new seabios CBFS image. # CBFSFILE=seabios.cbfs $ dd if=/dev/zero of=bootblock count=1 bs=64 2> /dev/null $CBFSTOOL $CBFSFILE create -s $(( 2*1024*1024 )) -B bootblock -m x86 # # Add SeaVGABIOS to CBFS # $CBFSTOOL $CBFSFILE add-payload -f $PAYLOAD -n payload -c lzma # # Add SeaBIOS payload to CBFS # $ CBFSTOOL $CBFSFILE add -f $PAYLOADVGA -n vgaroms/seavgabios.rom -t optionrom Question - if it is work under construction, the above may or may not show any VGA output? i.e. black screen Or give it a whirl, and I may surprise myself? Or stick with ## Extract vgabios from SeaBIOS CBFS area of original image. ORIGCBFSFILE=orig-seabios.cbfs $ dd if=$ORIGIMAGE of=$ORIGCBFSFILE skip=2 bs=2M count=1 2> /dev/null $ CBFSTOOL $ORIGCBFSFILE extract -n pci8086,0406.rom -f pci8086,0406.rom $ CBFSTOOL $CBFSFILE add -f pci8086,0406.rom -n pci8086,0a06.rom -t optionrom Edward On Fri, Dec 4, 2015 at 5:50 PM, edward wandasiewicz <0.w3ntd(a)gmail.com> wrote: > Looking at the output from Googles ChromeOS shell-ball, I do: > > Write the hardware ID to get future ChromeOS updates > > $ ./gbb_utility --set --hwid="SAMUS XXX-YYY-ZZZ" bios.bin bios.hwid.bin > > # dd out 2 megs of the ROM at 4 megs in > > $ dd bs=1M skip=4 count=2 if=bios.hwid.bin of=rwlegacy.cbfs > > Using the flashrom from John's site as upstream doesn't know anything about > flashmap. > > $ wget https://johnlewis.ie/Chromebook-ROMs/utils/flashrom -O > flashrom.jlewis > > $ sudo ./flashrom.jlewis -w -i RW_LEGACY:rwlegacy.cbfs > > Looking at your script, ORIGIMAGE is my bios.hwid.bin > > Do I run flashrom from the shell-ball > > $ sudo flashrom -w ./newimage.rom -i RW_LEGACY > > Or John Lewis flashrom > > $ sudo flashrom.jlewis.version -w ./newimage.rom -i RW_LEGACY > > Edward > > On 1 Dec 2015 3:39 p.m., "Kevin O'Connor" <kevin(a)koconnor.net> wrote: >> >> On Mon, Nov 30, 2015 at 07:04:55PM +0000, edward wandasiewicz wrote: >> > On 30 Nov 2015 5:35 p.m., "Kevin O'Connor" <kevin(a)koconnor.net> wrote: >> > > Looks like two separate issues are occurring - the Philips drive is >> > > being detected as both a high speed device and as a super speed >> > > device. I need a log with CONFIG_DEBUG_LEVEL=5 to diagnose that. The >> > > second issue appears to be a USB_TRANSACTION_ERROR response from the >> > > set_address command. I think the controller may just be a bit too >> > > picky on stall responses from devices in that situation. I've put up >> > > a patch to try and work around that in the repo at: >> > > >> > > https://github.com/KevinOConnor/seabios/tree/testing >> > > >> > > Are you able to compile SeaBIOS from source and install it on your >> > > Samus? >> > >> > Compile? I could have a go, but don't want to brick my device. Happy >> > to write a RW_LEGACY from John Lewis. >> > >> > Or learn how to - bit risky for a newbie? >> >> If you've never removed the flash read/write screw (and you normally >> hit cntl-L to enter seabios) then bricking shouldn't be a problem. >> (No guarantees.) It may require a full chrome re-install to recover >> should something go wrong though. If you have removed the read/write >> screw then you should only proceed if you know what you are doing, and >> you should have the ability to restore from an external flasher. >> >> Roughly, the steps to build and flash a RW_LEGACY section is as >> follows: >> >> 1 - grab the code: >> >> git clone https://github.com/KevinOConnor/seabios.git -b testing >> >> 2 - build the code: >> >> cd seabios >> echo "CONFIG_COREBOOT=y" > .config >> echo "CONFIG_CBFS_LOCATION=0xffe00000" >> .config >> echo "CONFIG_VGA_COREBOOT=y" >> .config >> echo "CONFIG_DEBUG_LEVEL=5" >> .config >> make olddefconfig >> make >> >> 3 - build the RW_LEGACY image by copying the attached chromeimage.sh >> to the seabios directory, make it executable, and run the script: >> >> ./chromeimage.sh >> >> Be sure to follow the directions in that script for extracting the >> original image and for writing the generated image. >> >> Please review the script and make sure it makes sense before running >> anything. If you don't understand a step then you probably will want >> to hold off until someone can build a tested rom for you. >> >> Cheers, >> -Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor 04 Dec '15

04 Dec '15

On Mon, Nov 30, 2015 at 07:04:55PM +0000, edward wandasiewicz wrote: > On 30 Nov 2015 5:35 p.m., "Kevin O'Connor" <kevin(a)koconnor.net> wrote: > > Looks like two separate issues are occurring - the Philips drive is > > being detected as both a high speed device and as a super speed > > device. I need a log with CONFIG_DEBUG_LEVEL=5 to diagnose that. The > > second issue appears to be a USB_TRANSACTION_ERROR response from the > > set_address command. I think the controller may just be a bit too > > picky on stall responses from devices in that situation. I've put up > > a patch to try and work around that in the repo at: > > > > https://github.com/KevinOConnor/seabios/tree/testing > > > > Are you able to compile SeaBIOS from source and install it on your > > Samus? > > Compile? I could have a go, but don't want to brick my device. Happy > to write a RW_LEGACY from John Lewis. > > Or learn how to - bit risky for a newbie? If you've never removed the flash read/write screw (and you normally hit cntl-L to enter seabios) then bricking shouldn't be a problem. (No guarantees.) It may require a full chrome re-install to recover should something go wrong though. If you have removed the read/write screw then you should only proceed if you know what you are doing, and you should have the ability to restore from an external flasher. Roughly, the steps to build and flash a RW_LEGACY section is as follows: 1 - grab the code: git clone https://github.com/KevinOConnor/seabios.git -b testing 2 - build the code: cd seabios echo "CONFIG_COREBOOT=y" > .config echo "CONFIG_CBFS_LOCATION=0xffe00000" >> .config echo "CONFIG_VGA_COREBOOT=y" >> .config echo "CONFIG_DEBUG_LEVEL=5" >> .config make olddefconfig make 3 - build the RW_LEGACY image by copying the attached chromeimage.sh to the seabios directory, make it executable, and run the script: ./chromeimage.sh Be sure to follow the directions in that script for extracting the original image and for writing the generated image. Please review the script and make sure it makes sense before running anything. If you don't understand a step then you probably will want to hold off until someone can build a tested rom for you. Cheers, -Kevin

2 1

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Xulei (Stone) 02 Dec '15

02 Dec '15

> >>On Sat, Nov 28, 2015 at 07:12:47AM +0000, Xulei (Stone) wrote: > >>> Hi, > >>> Recently, i use a script to continuously reset a VM and > >>> i found my VM frequently halts at "Attempting to allocate > >>> VGA stack via pmm call". After analyzing, i think it may > >>> be a problem of SeaBIOS. > >>> > >>> From the log(attached below), we can see handle_post() > >>> executes twice and this makes the destination address of > >>> "Relocating init" change when the 2nd reset command comes. > >>> This also influences on the source address of "Copying MPTABLE". > >>> At last, the VM will be stuck at attempting to allocate VGA > >>> stack via pmm call. > >>> > >>> Could you offer me a solution to fix this problem? > >>> > >>> ==============bad SeaBIOS log====== > >>> SeaBIOS (version rel-1.8.1-0-g4adadbd-20151127_220019-UVP) > >>> No Xen hypervisor found. > >>> Running on QEMU (i440fx) > >>> Running on KVM > >>> RamSize: 0xc0000000 [cmos] > >>> Now vcpu cpu_id = 0 > >>> Relocating init from 0x000dbb30 to 0xbffad2c0 (size 76928) > >>> Found QEMU fw_cfg > >>> SeaBIOS (version rel-1.8.1-0-g4adadbd-20151127_220019-UVP) <<========= handle_post() execute again? > >> > >>If seabios resets before it sets HaveRunPost then it probably wont > >>work well, as it will rerun the POST code without resetting the global > >>variables it has modified. > >> > >>Unfortunately, it's not clear to me that we can simply move the > >>setting of HaveRunPost to an earlier point, as the handle_resume() > >>code would need to be audited to ensure it can run even if POST hasn't > >>completed. > > > >I move HaveRunPost = 1 in the very early point of POST phase (begin > >at handle_post()), so that when the 2nd reset comes, HaveRunPost is > >already 1 which makes entry_post jmps to handle_resume() instead of > >handle_post(). As we know, handle_resume() will reset all global variables. > > > >Can you tell me is this solution ok? or, does this have some side effects? > > Sorry, i've tested and this seems not work. Let HaveRunPost = 1 at begin > of handle_post(), will lead the VM to loop forever in the resume phase. > It seems the memcpy() in qemu_prep_reset()can not clear HaveRunPost at > this time. > > Ah! I'm confused! I don't know where is the right place to let HaveRunPost = 1? I move HaveRunPost = 1 to handle_post() (after make_bios_writable()), and I have tested for 1 day with continuously resetting, it seems works well! Does following patch have some side effects? f65091856d257f2c232263ac4bbc29457f356efe src/post.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/post.c b/src/post.c index 49c22b8..f381385 100644 --- a/src/post.c +++ b/src/post.c @@ -41,9 +41,7 @@ ivt_init(void) { dprintf(3, "init ivt\n"); - // Setup reset-vector entry point (controls legacy reboots). - HaveRunPost = 1; - rtc_write(CMOS_RESET_CODE, 0); // Initialize all vectors to the default handler. int i; @@ -335,6 +333,10 @@ handle_post(void) // Allow writes to modify bios area (0xf0000) make_bios_writable(); + // Setup reset-vector entry point (controls legacy reboots). + HaveRunPost = 1; + rtc_write(CMOS_RESET_CODE, 0); + // Now that memory is read/writable - start post process. dopost(); } > >>So, it looks like a fix for this will take some further analysis. > >> > >>-Kevin

1 0

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Xulei (Stone) 01 Dec '15

01 Dec '15

> > >>On Sat, Nov 28, 2015 at 07:12:47AM +0000, Xulei (Stone) wrote: >>> Hi, >>> Recently, i use a script to continuously reset a VM and >>> i found my VM frequently halts at "Attempting to allocate >>> VGA stack via pmm call". After analyzing, i think it may >>> be a problem of SeaBIOS. >>> >>> From the log(attached below), we can see handle_post() >>> executes twice and this makes the destination address of >>> "Relocating init" change when the 2nd reset command comes. >>> This also influences on the source address of "Copying MPTABLE". >>> At last, the VM will be stuck at attempting to allocate VGA >>> stack via pmm call. >>> >>> Could you offer me a solution to fix this problem? >>> >>> ==============bad SeaBIOS log====== >>> SeaBIOS (version rel-1.8.1-0-g4adadbd-20151127_220019-UVP) >>> No Xen hypervisor found. >>> Running on QEMU (i440fx) >>> Running on KVM >>> RamSize: 0xc0000000 [cmos] >>> Now vcpu cpu_id = 0 <<========= i add >>> Static seabios entry times =1 <<========= i add >>> Relocating init from 0x000dbb30 to 0xbffad2c0 (size 76928) >>> Found QEMU fw_cfg >>> SeaBIOS (version rel-1.8.1-0-g4adadbd-20151127_220019-UVP) <<========= handle_post() execute again? >> >>If seabios resets before it sets HaveRunPost then it probably wont >>work well, as it will rerun the POST code without resetting the global >>variables it has modified. >> >>Unfortunately, it's not clear to me that we can simply move the >>setting of HaveRunPost to an earlier point, as the handle_resume() >>code would need to be audited to ensure it can run even if POST hasn't >>completed. > >I move HaveRunPost = 1 in the very early point of POST phase (begin >at handle_post()), so that when the 2nd reset comes, HaveRunPost is >already 1 which makes entry_post jmps to handle_resume() instead of >handle_post(). As we know, handle_resume() will reset all global variables. > >Can you tell me is this solution ok? or, does this have some side effects? Sorry, i've tested and this seems not work. Let HaveRunPost = 1 at begin of handle_post(), will lead the VM to loop forever in the resume phase. It seems the memcpy() in qemu_prep_reset()can not clear HaveRunPost at this time. Ah! I'm confused! I don't know where is the right place to let HaveRunPost = 1? >>So, it looks like a fix for this will take some further analysis. >> >>-Kevin

1 0

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Kevin O'Connor 01 Dec '15

01 Dec '15

On Sat, Nov 28, 2015 at 07:12:47AM +0000, Xulei (Stone) wrote: > Hi, > Recently, i use a script to continuously reset a VM and > i found my VM frequently halts at "Attempting to allocate > VGA stack via pmm call". After analyzing, i think it may > be a problem of SeaBIOS. > > From the log(attached below), we can see handle_post() > executes twice and this makes the destination address of > "Relocating init" change when the 2nd reset command comes. > This also influences on the source address of "Copying MPTABLE". > At last, the VM will be stuck at attempting to allocate VGA > stack via pmm call. > > Could you offer me a solution to fix this problem? > > ==============bad SeaBIOS log====== > SeaBIOS (version rel-1.8.1-0-g4adadbd-20151127_220019-UVP) > No Xen hypervisor found. > Running on QEMU (i440fx) > Running on KVM > RamSize: 0xc0000000 [cmos] > Now vcpu cpu_id = 0 <<========= i add > Static seabios entry times =1 <<========= i add > Relocating init from 0x000dbb30 to 0xbffad2c0 (size 76928) > Found QEMU fw_cfg > SeaBIOS (version rel-1.8.1-0-g4adadbd-20151127_220019-UVP) <<========= handle_post() execute again? If seabios resets before it sets HaveRunPost then it probably wont work well, as it will rerun the POST code without resetting the global variables it has modified. Unfortunately, it's not clear to me that we can simply move the setting of HaveRunPost to an earlier point, as the handle_resume() code would need to be audited to ensure it can run even if POST hasn't completed. So, it looks like a fix for this will take some further analysis. -Kevin

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS December 2015