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" <[email protected]> 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" <[email protected]> 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 < >> [email protected]> 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-e6xx-boot-requirements-app-note.html >>> >>> 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: [email protected] >>> http://www.coreboot.org/mailman/listinfo/coreboot >>> >> >>
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
