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
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
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
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
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
>
>
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
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
>>>
>>
>>
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?
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
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.
