coreboot March 2015

coreboot@coreboot.org

62 participants
166 discussions

Booting Windows 8 failed
by WANG Siyuan 24 Mar '15

24 Mar '15

I am porting the coreboot to a platform with a new AMD APU, which is close to Kabini and Mullins. Now the board can boot Ubuntu and Windows 7. But it failed to boot Windows 8. It crashes at a very early stage, which seems to be Windows bootloader. The debug message of SeaBIOS is attached. The interrupt routine installed by SeaBIOS still work. We can see handle_13, handle_08, handle_1a are called once in a while. There is no BSOD. There is only a windows logo on the monitor, without progress ring of Windows 8. Even the debug version of windows 8 doesn't help, because it crashes before the image is loaded. Is there any more way to debug windows 8 bootloader? Zheng serial output --------------------- ....... ....... handle_08 enter handle_15: a=0000e820 b=00000006 c=00000018 d=534d4150 ds=0000 es=3004 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a25 f=0256 enter handle_13: a=00004200 b=00000000 c=00000000 d=00000080 ds=3024 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a1d f=0256 disk_op d=0x000f98e0 lba=0 buf=0x00030000 count=1 cmd=2 AHCI/0: send cmd ... handle_08 AHCI/0: ... intbits 0x1, status 0x50 ... AHCI/0: ... finished, status 0x50, OK ahci disk read, lba 0, count 1, buf 0x00030000, rc 0 enter handle_13: a=00004200 b=00000000 c=00000000 d=00000080 ds=3204 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a1d f=0256 disk_op d=0x000f98e0 lba=2048 buf=0x00030000 count=16 cmd=2 AHCI/0: send cmd ... AHCI/0: ... intbits 0x1, status 0x50 ... AHCI/0: ... finished, status 0x50, OK ahci disk read, lba 800, count 10, buf 0x00030000, rc 0 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 handle_08 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_13: a=00004200 b=00000000 c=00000000 d=00000080 ds=3804 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a1d f=0256 disk_op d=0x000f98e0 lba=7166912 buf=0x00030000 count=64 cmd=2 AHCI/0: send cmd ... handle_08 AHCI/0: ... intbits 0x1, status 0x50 ... AHCI/0: ... finished, status 0x50, OK ahci disk read, lba 6d5bc0, count 40, buf 0x00030000, rc 0 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_13: a=00004200 b=00000000 c=00000000 d=00000080 ds=3204 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a1d f=0256 disk_op d=0x000f98e0 lba=31249832 buf=0x00030000 count=16 cmd=2 AHCI/0: send cmd ... handle_08 AHCI/0: ... intbits 0x1, status 0x50 ... AHCI/0: ... finished, status 0x50, OK ahci disk read, lba 1dcd5a8, count 10, buf 0x00030000, rc 0 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 handle_08 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000200 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000400 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 handle_08 agesawrapper_amdinitmmio() entry agesawrapper_amdinitmmio() returned AGESA_SUCCESS coreboot-4.0-6798-gdd6d81f-dirty Thu Mar 19 20:02:01 CST 2015 starting... BSP Family_Model: cpu_init_detectedx = 00000000 agesawrapper_amdinitreset() entry AmdCreateStruct, 188, InterfaceParams->StdHeader.HeapBasePtr=400000 Fch OEM config in INIT RESET Done agesawrapper_amdinitreset() returned AGESA_SUCCESS Got past agesawrapper_amdinitreset agesawrapper_amdinitearly() entry AmdCreateStruct, 188, InterfaceParams->StdHeader.HeapBasePtr=400000 AmdInitEarly, 239, &EarlyParams->StdHeader=400290 AmdInitEarly, 247, EarlyParams->StdHeader=0 AmdInitEarly, 273, EarlyParams->StdHeader=0 AmdInitEarly, 283, EarlyParams->StdHeader=0 AmdInitEarly, 297, EarlyParams->StdHeader=0 GnbGetScsDataCZ, 183:PspDir=ff860000 Yours sincerely, WANG Siyuan

1 0

[Coreboot] Booting Windows 8 failed
by Bao, Zheng 24 Mar '15

24 Mar '15

I am porting the coreboot to a platform with a new AMD APU, which is close to Kabini and Mullins. Now the board can boot Ubuntu and Windows 7. But it failed to boot Windows 8. It crashes at a very early stage, which seems to be Windows bootloader. The debug message of SeaBIOS is attached. The interrupt routine installed by SeaBIOS still work. We can see handle_13, handle_08, handle_1a are called once in a while. There is no BSOD. There is only a windows logo on the monitor, without progress ring of Windows 8. Even the debug version of windows 8 doesn't help, because it crashes before the image is loaded. Is there any more way to debug windows 8 bootloader? Joe serial output --------------------- ....... ....... handle_08 enter handle_15: a=0000e820 b=00000006 c=00000018 d=534d4150 ds=0000 es=3004 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a25 f=0256 enter handle_13: a=00004200 b=00000000 c=00000000 d=00000080 ds=3024 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a1d f=0256 disk_op d=0x000f98e0 lba=0 buf=0x00030000 count=1 cmd=2 AHCI/0: send cmd ... handle_08 AHCI/0: ... intbits 0x1, status 0x50 ... AHCI/0: ... finished, status 0x50, OK ahci disk read, lba 0, count 1, buf 0x00030000, rc 0 enter handle_13: a=00004200 b=00000000 c=00000000 d=00000080 ds=3204 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a1d f=0256 disk_op d=0x000f98e0 lba=2048 buf=0x00030000 count=16 cmd=2 AHCI/0: send cmd ... AHCI/0: ... intbits 0x1, status 0x50 ... AHCI/0: ... finished, status 0x50, OK ahci disk read, lba 800, count 10, buf 0x00030000, rc 0 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 handle_08 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_13: a=00004200 b=00000000 c=00000000 d=00000080 ds=3804 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a1d f=0256 disk_op d=0x000f98e0 lba=7166912 buf=0x00030000 count=64 cmd=2 AHCI/0: send cmd ... handle_08 AHCI/0: ... intbits 0x1, status 0x50 ... AHCI/0: ... finished, status 0x50, OK ahci disk read, lba 6d5bc0, count 40, buf 0x00030000, rc 0 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_13: a=00004200 b=00000000 c=00000000 d=00000080 ds=3204 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a1d f=0256 disk_op d=0x000f98e0 lba=31249832 buf=0x00030000 count=16 cmd=2 AHCI/0: send cmd ... handle_08 AHCI/0: ... intbits 0x1, status 0x50 ... AHCI/0: ... finished, status 0x50, OK ahci disk read, lba 1dcd5a8, count 10, buf 0x00030000, rc 0 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 handle_08 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000200 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000400 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 handle_08 agesawrapper_amdinitmmio() entry agesawrapper_amdinitmmio() returned AGESA_SUCCESS coreboot-4.0-6798-gdd6d81f-dirty Thu Mar 19 20:02:01 CST 2015 starting... BSP Family_Model: cpu_init_detectedx = 00000000 agesawrapper_amdinitreset() entry AmdCreateStruct, 188, InterfaceParams->StdHeader.HeapBasePtr=400000 Fch OEM config in INIT RESET Done agesawrapper_amdinitreset() returned AGESA_SUCCESS Got past agesawrapper_amdinitreset agesawrapper_amdinitearly() entry AmdCreateStruct, 188, InterfaceParams->StdHeader.HeapBasePtr=400000 AmdInitEarly, 239, &EarlyParams->StdHeader=400290 AmdInitEarly, 247, EarlyParams->StdHeader=0 AmdInitEarly, 273, EarlyParams->StdHeader=0 AmdInitEarly, 283, EarlyParams->StdHeader=0 AmdInitEarly, 297, EarlyParams->StdHeader=0 GnbGetScsDataCZ, 183:PspDir=ff860000

1 0

Re: [coreboot] VGA doesn't work on Mohon Peak
by Kevin O'Connor 24 Mar '15

24 Mar '15

Just to be clear, it's fine to try initializing the video card in SeaBIOS, it's fine to try initializing the video card in coreboot, and it's fine to try and hold off initialization until Linux starts. But, definitely don't try booting with two or more points trying to initialize the video hardware - that's known to cause problems. When attempting to initialize the video hardware in SeaBIOS, make sure coreboot has CONFIG_VGA_ROM_RUN, CONFIG_ON_DEVICE_ROM_RUN, CONFIG_VGA_BIOS, and CONFIG_PXE_ROM all disabled. If attempting to initialize the video in coreboot or Linux, then one must force SeaBIOS to not attempt to run the vga option rom - the easiest way to do this is to use the latest development seabios code and set /etc/pci-optionrom-exec to 0 (see http://www.coreboot.org/SeaBIOS#Other_Configuration_items ). -Kevin On Sun, Mar 22, 2015 at 05:32:32PM +0000, ron minnich wrote: > A good first pass is to enable YABEL instead of native execution and watch > what it does. That's how I've had to debug graphics before. > > Also, if you can do a serial console only setup, you can run the VBIOS once > linux is booted and try to debug it that way. > > It's very hard to debug a VBIOS issue as you are doing it now, however. It > will take years off of your life :-) > > ron > > On Sun, Mar 22, 2015 at 9:07 AM Martin Roth <gaumless(a)gmail.com> wrote: > > > My experience is that the aspeed chip based graphics card that comes with > > Mohon Peak has a bug in the vbios causing it to hang when run. If you need > > to use this specific card, you'll need to debug it, probably with a jtag > > debugger, going through the assembly, and see what's causing the issue. My > > initial guess is that they're looking for some value in the bda or ebda > > that isn't present, but I'm not sure what this might be. > > > > Martin > > > > On Sun, Mar 22, 2015 at 8:45 AM, Kevin O'Connor <kevin(a)koconnor.net> > > wrote: > > > >> On Fri, Mar 20, 2015 at 12:30:38PM +0300, Kuzmichev Viktor wrote: > >> > I tried not to include any VBIOS file in coreboot ROM much earlier, in > >> my > >> > first tests. With 'Run VGA Option ROMs' option checked the board just > >> hung. > >> > > >> > And as I mentioned in my previous email VGA works fine with vendor's > >> BIOS. > >> > So the card itself should be fine. > >> > > >> > Sadly, I don't have another card to try. Even if I had, I still would > >> need > >> > to make this one work somehow as Mohon Peak is just a reference board > >> and > >> > the target board will have a similar VGA controller. > >> > > >> > So please, let me know if there are some other things I could try or if > >> I am > >> > mistaken somewhere. > >> > >> Hi Viktor, > >> > >> It seems you've tried a bunch of different configurations. However, > >> this is making your trouble report hard to understand as it becomes > >> unclear which config had which results. > >> > >> If you have an external VGA card, then please build coreboot with > >> CONFIG_VGA_ROM_RUN, CONFIG_ON_DEVICE_ROM_RUN, CONFIG_VGA_BIOS, and > >> CONFIG_PXE_ROM all disabled. Please use either the SeaBIOS provided > >> by coreboot, or build SeaBIOS with a default config (only > >> CONFIG_COREBOOT and if needed CONFIG_DEBUG_SERIAL changed from the > >> seabios defaults). This is described at: > >> http://www.coreboot.org/SeaBIOS > >> > >> In particular, there should be no "pciXXXX,YYYY.rom" or "vgaroms/XXX" > >> files in your cbfs rom. > >> > >> If the above does not work, please use the above config and recompile > >> SeaBIOS at debug level 8, and post the full debug log along with the > >> output of "cbfstool print". > >> > >> Cheers, > >> -Kevin > >> > >> -- > >> coreboot mailing list: coreboot(a)coreboot.org > >> http://www.coreboot.org/mailman/listinfo/coreboot > >> > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot

2 1

Re: [coreboot] Regarding gsoc
by Vadim Bendebury 23 Mar '15

23 Mar '15

That's the spirit! -vb On Mon, Mar 23, 2015 at 2:10 AM, Kushagra Kumar <kushagra.nasa(a)gmail.com> wrote: > I believe impossible can be done I believe I can do it.today m going to do > smthng to help coreboot wish me luck guys.I will tell type again in 5 > hours.god bless me nd m very excited. > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] 0xE0000/0xF0000 segment issue
by Naresh G. Solanki 23 Mar '15

23 Mar '15

Currently I'm porting coreboot for atom e6xx processor board. This correction is a part of it. Few more minor corrections to come. Once I feel its fully stable and reliable then I'll update it in git. My best try is to add the processor in coreboot supported procesor list - N Solanki On 23 Mar 2015 23:16, "ron minnich" <rminnich(a)gmail.com> wrote: > Nice job, documents are almost always full of errors :-) > > Any way you can create a patch for some part of some code base? This email > will be forgotten quickly and we want > your hard-earned knowledge :-) > > ron > > On Mon, Mar 23, 2015 at 10:43 AM Naresh G. Solanki < > naresh.solanki.2011(a)gmail.com> wrote: > >> Hi All, >> >> I was facing difficulty in enabling 0xE0000 & 0xF0000 segment on intel >> atom e6xx processor. >> >> As per guide (atom e6xx minimum boot requirements) in table 15 it was >> mentioned that the segment can be enabled by setting bit 1 & 2 of port 0 >> reg offset 3. I tried but it failed. >> >> I needed it to execute seabios successfully. >> >> By trial & error I found that instead of port 0 if I tried setting the >> bits in port 2 offset 3 , it served my purpose completely.( I think its >> wrongly documented in the guide I was refering) >> >> Now I'm able to execute seabios successfully. >> >> This post is just for your information, if in case it can help any one. >> >> Thank you for support. >> >> - N Solanki >> On 20 Mar 2015 21:03, "Naresh G. Solanki" <naresh.solanki.2011(a)gmail.com> >> wrote: >> >>> As per reply from seabios mailing list, >>> the address range 0xE0000 to 0x10_0000 should have read write access and >>> that can be done with help of some magic bit. >>> >>> Does anyone knows about these magic bits. >>> The processor I'm working with is atom e6xx. >>> >>> -N Solanki >>> On 20 Mar 2015 19:24, "WANG FEI" <wangfei.jimei(a)gmail.com> wrote: >>> >>>> I'm curious why your seabios payload is loading to shadow RAM >>>> (C/D/E/F000 segment), this area suppose to be used by seabios, I guess >>>> since seabios is a legacy BIOS. My suggestion is to load your seabios to a >>>> over 1MB address. >>>> >>>> On Thu, Mar 19, 2015 at 2:38 PM, Naresh G. Solanki < >>>> naresh.solanki.2011(a)gmail.com> wrote: >>>> >>>>> Hi All, >>>>> >>>>> >>>>> I'm trying to port coreboot with seabios payload. >>>>> Everything goes fine till the control is transferred to payload. >>>>> >>>>> Since payload is loaded between memory range 0xC_0000 - 0x10_0000. >>>>> >>>>> The problem I was facing was that the board was going to auto reboot >>>>> mode while executing payload.. >>>>> >>>>> Once it reboot then I'm not able to control the processor through XDP >>>>> until I manually do CPU reset. >>>>> >>>>> It keeps on rebooting once control is transferred to payload. >>>>> >>>>> >>>>> To find out the cause I did detailed memory test & found out that the >>>>> memory range 0xA0000 - 0xBFFFF & 0xE0000 - 0xFFFFF always reads 0xFF. >>>>> >>>>> since payload is loaded in the same region so before jmp_payload, I >>>>> tried to read this region through XDP & found payload code exist. >>>>> >>>>> so I introduced wbinvd instruction just before jmp_payload & I found >>>>> that the XDP started reading 0xFF in the memory range 0xE0000 - 0xFFFFF. >>>>> >>>>> Thus from this I conclude that before the payload was able to execute >>>>> because of cached copy of it in CPU cache & it didn't really existed in RAM. >>>>> >>>>> Also to enable memory range 0xE_0000 to 0xF_FFFF I have followed the >>>>> guidlines as per table 15 of the document >>>>> >>>>> http://www.intel.com/content/www/us/en/intelligent-systems/queens-bay/atom-… >>>>> >>>>> Is that OK. >>>>> What I can do to successfully enable the memory range 0xE_0000 to >>>>> 0xF_FFFF for read write operation so that my payload execution goes >>>>> undisturbed. >>>>> >>>>> My ultimate aim is to load Windows by Seabios as payload. >>>>> >>>>> Thanks >>>>> N Solanki >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> coreboot mailing list: coreboot(a)coreboot.org >>>>> http://www.coreboot.org/mailman/listinfo/coreboot >>>>> >>>> >>>> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot > >

1 0

Re: [coreboot] 0xE0000/0xF0000 segment issue
by ron minnich 23 Mar '15

23 Mar '15

Nice job, documents are almost always full of errors :-) Any way you can create a patch for some part of some code base? This email will be forgotten quickly and we want your hard-earned knowledge :-) ron On Mon, Mar 23, 2015 at 10:43 AM Naresh G. Solanki < naresh.solanki.2011(a)gmail.com> wrote: > Hi All, > > I was facing difficulty in enabling 0xE0000 & 0xF0000 segment on intel > atom e6xx processor. > > As per guide (atom e6xx minimum boot requirements) in table 15 it was > mentioned that the segment can be enabled by setting bit 1 & 2 of port 0 > reg offset 3. I tried but it failed. > > I needed it to execute seabios successfully. > > By trial & error I found that instead of port 0 if I tried setting the > bits in port 2 offset 3 , it served my purpose completely.( I think its > wrongly documented in the guide I was refering) > > Now I'm able to execute seabios successfully. > > This post is just for your information, if in case it can help any one. > > Thank you for support. > > - N Solanki > On 20 Mar 2015 21:03, "Naresh G. Solanki" <naresh.solanki.2011(a)gmail.com> > wrote: > >> As per reply from seabios mailing list, >> the address range 0xE0000 to 0x10_0000 should have read write access and >> that can be done with help of some magic bit. >> >> Does anyone knows about these magic bits. >> The processor I'm working with is atom e6xx. >> >> -N Solanki >> On 20 Mar 2015 19:24, "WANG FEI" <wangfei.jimei(a)gmail.com> wrote: >> >>> I'm curious why your seabios payload is loading to shadow RAM >>> (C/D/E/F000 segment), this area suppose to be used by seabios, I guess >>> since seabios is a legacy BIOS. My suggestion is to load your seabios to a >>> over 1MB address. >>> >>> On Thu, Mar 19, 2015 at 2:38 PM, Naresh G. Solanki < >>> naresh.solanki.2011(a)gmail.com> wrote: >>> >>>> Hi All, >>>> >>>> >>>> I'm trying to port coreboot with seabios payload. >>>> Everything goes fine till the control is transferred to payload. >>>> >>>> Since payload is loaded between memory range 0xC_0000 - 0x10_0000. >>>> >>>> The problem I was facing was that the board was going to auto reboot >>>> mode while executing payload.. >>>> >>>> Once it reboot then I'm not able to control the processor through XDP >>>> until I manually do CPU reset. >>>> >>>> It keeps on rebooting once control is transferred to payload. >>>> >>>> >>>> To find out the cause I did detailed memory test & found out that the >>>> memory range 0xA0000 - 0xBFFFF & 0xE0000 - 0xFFFFF always reads 0xFF. >>>> >>>> since payload is loaded in the same region so before jmp_payload, I >>>> tried to read this region through XDP & found payload code exist. >>>> >>>> so I introduced wbinvd instruction just before jmp_payload & I found >>>> that the XDP started reading 0xFF in the memory range 0xE0000 - 0xFFFFF. >>>> >>>> Thus from this I conclude that before the payload was able to execute >>>> because of cached copy of it in CPU cache & it didn't really existed in RAM. >>>> >>>> Also to enable memory range 0xE_0000 to 0xF_FFFF I have followed the >>>> guidlines as per table 15 of the document >>>> >>>> http://www.intel.com/content/www/us/en/intelligent-systems/queens-bay/atom-… >>>> >>>> Is that OK. >>>> What I can do to successfully enable the memory range 0xE_0000 to >>>> 0xF_FFFF for read write operation so that my payload execution goes >>>> undisturbed. >>>> >>>> My ultimate aim is to load Windows by Seabios as payload. >>>> >>>> Thanks >>>> N Solanki >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> coreboot mailing list: coreboot(a)coreboot.org >>>> http://www.coreboot.org/mailman/listinfo/coreboot >>>> >>> >>> -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] 0xE0000/0xF0000 segment issue
by Naresh G. Solanki 23 Mar '15

23 Mar '15

Hi All, I was facing difficulty in enabling 0xE0000 & 0xF0000 segment on intel atom e6xx processor. As per guide (atom e6xx minimum boot requirements) in table 15 it was mentioned that the segment can be enabled by setting bit 1 & 2 of port 0 reg offset 3. I tried but it failed. I needed it to execute seabios successfully. By trial & error I found that instead of port 0 if I tried setting the bits in port 2 offset 3 , it served my purpose completely.( I think its wrongly documented in the guide I was refering) Now I'm able to execute seabios successfully. This post is just for your information, if in case it can help any one. Thank you for support. - N Solanki On 20 Mar 2015 21:03, "Naresh G. Solanki" <naresh.solanki.2011(a)gmail.com> wrote: > As per reply from seabios mailing list, > the address range 0xE0000 to 0x10_0000 should have read write access and > that can be done with help of some magic bit. > > Does anyone knows about these magic bits. > The processor I'm working with is atom e6xx. > > -N Solanki > On 20 Mar 2015 19:24, "WANG FEI" <wangfei.jimei(a)gmail.com> wrote: > >> I'm curious why your seabios payload is loading to shadow RAM (C/D/E/F000 >> segment), this area suppose to be used by seabios, I guess since seabios is >> a legacy BIOS. My suggestion is to load your seabios to a over 1MB address. >> >> On Thu, Mar 19, 2015 at 2:38 PM, Naresh G. Solanki < >> naresh.solanki.2011(a)gmail.com> wrote: >> >>> Hi All, >>> >>> >>> I'm trying to port coreboot with seabios payload. >>> Everything goes fine till the control is transferred to payload. >>> >>> Since payload is loaded between memory range 0xC_0000 - 0x10_0000. >>> >>> The problem I was facing was that the board was going to auto reboot >>> mode while executing payload.. >>> >>> Once it reboot then I'm not able to control the processor through XDP >>> until I manually do CPU reset. >>> >>> It keeps on rebooting once control is transferred to payload. >>> >>> >>> To find out the cause I did detailed memory test & found out that the >>> memory range 0xA0000 - 0xBFFFF & 0xE0000 - 0xFFFFF always reads 0xFF. >>> >>> since payload is loaded in the same region so before jmp_payload, I >>> tried to read this region through XDP & found payload code exist. >>> >>> so I introduced wbinvd instruction just before jmp_payload & I found >>> that the XDP started reading 0xFF in the memory range 0xE0000 - 0xFFFFF. >>> >>> Thus from this I conclude that before the payload was able to execute >>> because of cached copy of it in CPU cache & it didn't really existed in RAM. >>> >>> Also to enable memory range 0xE_0000 to 0xF_FFFF I have followed the >>> guidlines as per table 15 of the document >>> >>> http://www.intel.com/content/www/us/en/intelligent-systems/queens-bay/atom-… >>> >>> Is that OK. >>> What I can do to successfully enable the memory range 0xE_0000 to >>> 0xF_FFFF for read write operation so that my payload execution goes >>> undisturbed. >>> >>> My ultimate aim is to load Windows by Seabios as payload. >>> >>> Thanks >>> N Solanki >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> http://www.coreboot.org/mailman/listinfo/coreboot >>> >> >>

1 0

help regarding gsoc
by Kushagra Kumar 23 Mar '15

23 Mar '15

have been trying to get access to more hardware so that I can add compatibility.Sir I m interested in adding compatibility for RISCV.I have followed Ur previous instructions.what do u think will this project be good?

1 0

Booting Windows 8 failed.
by Bao, Zheng 23 Mar '15

23 Mar '15

I am porting the coreboot to a platform with a new AMD APU, which is close to Kabini and Mullins. Now the board can boot Ubuntu and Windows 7. But it failed to boot Windows 8. It crashes at a very early stage, which seems to be Windows bootloader. The debug message of SeaBIOS is attached. The interrupt routine installed by SeaBIOS still work. We can see handle_13, handle_08, handle_1a are called once in a while. There is no BSOD. There is only a windows logo on the monitor, without progress ring of Windows 8. Even the debug version of windows 8 doesn't help, because it crashes before the image is loaded. Is there any more way to debug windows 8 bootloader? Joe serial output --------------------- ....... ....... handle_08 enter handle_15: a=0000e820 b=00000006 c=00000018 d=534d4150 ds=0000 es=3004 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a25 f=0256 enter handle_13: a=00004200 b=00000000 c=00000000 d=00000080 ds=3024 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a1d f=0256 disk_op d=0x000f98e0 lba=0 buf=0x00030000 count=1 cmd=2 AHCI/0: send cmd ... handle_08 AHCI/0: ... intbits 0x1, status 0x50 ... AHCI/0: ... finished, status 0x50, OK ahci disk read, lba 0, count 1, buf 0x00030000, rc 0 enter handle_13: a=00004200 b=00000000 c=00000000 d=00000080 ds=3204 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a1d f=0256 disk_op d=0x000f98e0 lba=2048 buf=0x00030000 count=16 cmd=2 AHCI/0: send cmd ... AHCI/0: ... intbits 0x1, status 0x50 ... AHCI/0: ... finished, status 0x50, OK ahci disk read, lba 800, count 10, buf 0x00030000, rc 0 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 handle_08 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_13: a=00004200 b=00000000 c=00000000 d=00000080 ds=3804 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a1d f=0256 disk_op d=0x000f98e0 lba=7166912 buf=0x00030000 count=64 cmd=2 AHCI/0: send cmd ... handle_08 AHCI/0: ... intbits 0x1, status 0x50 ... AHCI/0: ... finished, status 0x50, OK ahci disk read, lba 6d5bc0, count 40, buf 0x00030000, rc 0 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_13: a=00004200 b=00000000 c=00000000 d=00000080 ds=3204 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a1d f=0256 disk_op d=0x000f98e0 lba=31249832 buf=0x00030000 count=16 cmd=2 AHCI/0: send cmd ... handle_08 AHCI/0: ... intbits 0x1, status 0x50 ... AHCI/0: ... finished, status 0x50, OK ahci disk read, lba 1dcd5a8, count 10, buf 0x00030000, rc 0 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 handle_08 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000200 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000400 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 enter handle_1a: a=00000000 b=00000000 c=00000000 d=00000000 ds=0000 es=0000 ss=9000 si=00000000 di=00000000 bp=00000000 sp=0000ffd6 cs=2000 ip=0a39 f=0256 handle_08 agesawrapper_amdinitmmio() entry agesawrapper_amdinitmmio() returned AGESA_SUCCESS coreboot-4.0-6798-gdd6d81f-dirty Thu Mar 19 20:02:01 CST 2015 starting... BSP Family_Model: cpu_init_detectedx = 00000000 agesawrapper_amdinitreset() entry AmdCreateStruct, 188, InterfaceParams->StdHeader.HeapBasePtr=400000 Fch OEM config in INIT RESET Done agesawrapper_amdinitreset() returned AGESA_SUCCESS Got past agesawrapper_amdinitreset agesawrapper_amdinitearly() entry AmdCreateStruct, 188, InterfaceParams->StdHeader.HeapBasePtr=400000 AmdInitEarly, 239, &EarlyParams->StdHeader=400290 AmdInitEarly, 247, EarlyParams->StdHeader=0 AmdInitEarly, 273, EarlyParams->StdHeader=0 AmdInitEarly, 283, EarlyParams->StdHeader=0 AmdInitEarly, 297, EarlyParams->StdHeader=0 GnbGetScsDataCZ, 183:PspDir=ff860000

1 0

Regarding gsoc
by Kushagra Kumar 23 Mar '15

23 Mar '15

I believe impossible can be done I believe I can do it.today m going to do smthng to help coreboot wish me luck guys.I will tell type again in 5 hours.god bless me nd m very excited.

1 0

← Newer
1
2
3
4
5
6
7
8
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2015