Re: [coreboot] Memory corruption on Resume from S3 Baytrail
Problem resolved by reserving initial 64K memory. Thanks to Stefan for his help. On Wed, Dec 10, 2014 at 11:12 AM, Gailu Singh wrote: > Hi, > > In coreboot developer manual memory map section ( > http://www.coreboot.org/Developer_Manual/Memory_map) there is specific > mention of low memory. > > *0x0 - 0x9*: Low 640kB. Should not be clobbered on S3 > suspend/resume (exceptions?) > > How do I tell Linux not to use this memory? I tried linux kernel argument > memap=640K@0x0 to reserve the space but my kernel does not boot with that. > > What changes are expected in Linux kernel configuration for S3 > suspend/resume to work smoothly with coreboot? > > > > > > On Sun, Nov 23, 2014 at 12:54 PM, Stefan Reinauer < > stefan.reina...@coreboot.org> wrote: > >> On 11/19/14 11:36 AM, Gailu Singh wrote: >> >>> Hi Experts, >>> >>> I am using Baytrail SoC board (Bayleybay CRB) and testing suspend/resume >>> from Linux (kernel 3.10). I can suspend with pm-suspend and resume with >>> power button; however after resuming I get following logs in Linux >>> Corrupted low memory at c0001004 (1004 phys) = 0008eaea >>> Corrupted low memory at c0001008 (1008 phys) = b0606600 >>> ... >>> Corrupted low memory at c00018fc (18fc phys) = 08ea >>> >>> This seems to be caused by coreboot as I do not see these logs if I use >>> BIOS instead of coreboot. >>> Is it true that during resume coreboot uses RAM portion already mapped >>> by Linux and thus corrupting it. How to I avoid the RAM conflict? >>> >> >> Looks like coreboot (or FSP) is overwriting this memory with some >> trampoline code. >> >> One (ugly) way to fix this would be to just reserve the space in the >> memory table. The better way would be to track down where this is actually >> happening and fix it there. >> >> Stefan >> > > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaBIOS wit USB3.0 hub and USB3.0 devide behind the hub
This is a complicated case most firmware USB stacks don't support (I don't have experience with SeaBIOS, but I know that both U-Boot and libpayload won't work with that either). A USB 3.0 hub is essentially two completely separate logical hubs connecting to two completely separate logical ports on the host. The USB 3.0 part of the hub uses a slightly different protocol (e.g. some bits in the port status have different meanings) and from a quick glance the SeaBIOS code doesn't seem to take that into account. I'm not sure where exactly it would break, but one possibility is the speed detection (in USB 2.0 the port status bits 9 and 10 indicate the speed, but in USB 3.0 it's implied to always be SuperSpeed and those two bits indicate the link state and the port power status instead). The speed is written in the XHCI Slot Context for the device and using the wrong value there might cause problems. If you just want a quick workaround, simply make the device enumerate at HighSpeed and it should work (only plugging the device "half-way" into the socket so that the SuperSpeed lines in the back of the plug don't connect usually does the trick). If you want it fixed someone would have to enhance the usb-hub driver to take all the peculiarities of USB 3.0 hubs into account. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaBIOS wit USB3.0 hub and USB3.0 devide behind the hub
On Wed, Dec 10, 2014 at 09:44:06PM -0800, Julius Werner wrote: > This is a complicated case most firmware USB stacks don't support (I > don't have experience with SeaBIOS, but I know that both U-Boot and > libpayload won't work with that either). A USB 3.0 hub is essentially > two completely separate logical hubs connecting to two completely > separate logical ports on the host. The USB 3.0 part of the hub uses a > slightly different protocol (e.g. some bits in the port status have > different meanings) and from a quick glance the SeaBIOS code doesn't > seem to take that into account. I'm not sure where exactly it would > break, but one possibility is the speed detection (in USB 2.0 the port > status bits 9 and 10 indicate the speed, but in USB 3.0 it's implied > to always be SuperSpeed and those two bits indicate the link state and > the port power status instead). The speed is written in the XHCI Slot > Context for the device and using the wrong value there might cause > problems. Right, SeaBIOS does not currently have USB3 hub specific code. The USB3 spec has close to 100 pages on hubs, but much of it resembles the USB2 hub details and it's not immiediately clear which parts differ. BTW, please CC the seabios mailing list on emails. -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
