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