SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

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

[PATCH 0/7] Some TPM code reorganization
by Kevin O'Connor 30 Nov '15

30 Nov '15

Hi Stefan, As part of trying to better understand the TPM code, I found some changes to tcgbios.c were helpful. It's mostly code movement. I've only compile tested these changes, but I think they are safe. I don't want to conflict with any changes you may have pending. So, let me know if this is a problem. The series is on top of your latest patches. (FYI, I made a minor change to a comment in your patch 2.) I've also put this series (and your series) up at: https://github.com/KevinOConnor/seabios/tree/testing -Kevin Kevin O'Connor (7): tpm: Add "static" declaration to functions not used outside tcgbios.c tpm: Move code around in tcgbios.c tpm: Move error recovery from tpm_extend_acpi_log() to only caller tpm: Open code tpm_ipl() into callers tpm: Change tpm_add_measurement() to tpm_add_action() tpm: Move tpm_add_bootdevice() into callers tpm: Move tpm_start_option_rom_scan() and tpm_calling_int19h() into callers src/tcgbios.c | 1258 +++++++++++++++++++++++++-------------------------------- 1 file changed, 556 insertions(+), 702 deletions(-) -- 2.5.0

3 17

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

30 Nov '15

On Mon, Nov 30, 2015 at 04:47:29PM +0000, edward wandasiewicz wrote: > I started over, as I forgot which device was in which port. > > It seem's like a race condition, as I managed to get a USB device > detected twice with JohnLewis RW_LEGACY as well now, although it > doesn't happen very frequently. I pressed Ctrl-L and ESC with not much > pause and got a double device detection. To confirm, the "double device" is an error right - there aren't actually two of these devices in the machine? 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? -Kevin

2 1

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

30 Nov '15

On Mon, Nov 30, 2015 at 03:22:38PM +0000, edward wandasiewicz wrote: > Booting with 1 x Phillips USB and 1 x Ventura Ultra attached to the Pixel 2015 > > I've attached the cbmem -c from Pixel Samus, after a cold boot into > Arch Linux and also following a reboot immediately after. > > After a reboot, following a boot, the Philips USB now only appears > just the once, and not twice as on a cold boot. > > I've attached a third cbmem -c, from John Lewis 11.11.15 SeaBIOS > RW_LEGACY for the Pixel Samus. [...] > ********************************** > * J.LEWIS 11.11.15 cold boot > ********************************** > > - same behaviour with JLEWIS on a cold boot and a reboot - no different > > $ cbmem -c > > http://pastebin.com/6XhANLkR Thanks. Can you boot to linux with the USB devices in the same ports as they were for the above boot and post the output from "lsusb -t" and "lsusb -v". Please just directly include or attach the output in your email. (pastebin doesn't work well for those using email archives.) -Kevin

2 1

Re: [SeaBIOS] [PATCH 3/3] tpm: Add a menu for TPM configuration
by Kevin O'Connor 30 Nov '15

30 Nov '15

On Mon, Nov 30, 2015 at 10:23:28AM -0500, Stefan Berger wrote: > "Kevin O'Connor" <kevin(a)koconnor.net> wrote on 11/30/2015 10:05:22 AM: > > Are the above definitions part of the standard, or internal to the > > implementation? If the latter, they should go into tcgbios.[ch] > > These are actually the 'message codes' from the physical presence > interface spec that can be sent from the OS > to the BIOS and on which the BIOS is supposed to act upon reboot. You may > remember the ACPI patches I had for QEMU > where ACPI would write one of the above number into an allocated memory > area for the BIOS to find. I also built > the menu using those 'message codes'. Okay, thanks. > > > +typedef struct { > > > + u8 op; > > > +} tpm_bios_cfg; > > > > What is the purpose of this struct? > > > > This datatype is used to send messages from menu item selections to the > part that processes above 'message codes'. Right, but why does it pass a pointer to the struct instead of just passing the u8 directly? > > > +extern void reset_vector(void) __noreturn; > > > > The code should use reset() (defined in stacks.h). Directly calling > > reset_vector() in 32bit mode isn't strictly correct. > > Ok, will change it. (Worked so far...) It works because it likely causes a machine exception which also ends up in a reboot. So, not as nice. Thanks, -Kevin

1 0

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

30 Nov '15

On Sun, Nov 29, 2015 at 01:40:08AM +0000, edward wandasiewicz wrote: > Running SeaBIOS on a Chromebook Pixel 2015, by default, does not > recognise a plugged in USB 3.0 device attached to a USB 3.0 port or > Type C port. In order for us to investigate an issue, we need to see the debug log. For chromebooks, this is normally obtained by booting a Linux OS from SeaBIOS and running "cbmem -c". It will likely be necessary to download and compile the cbmem utility from the coreboot source code. Once you have the log, please email both a success and failure case to this mail list. There is also some info at: http://www.seabios.org/Debugging -Kevin

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS