On Fri, Mar 28, 2014 at 05:08:03PM -0400, Michael Casadevall wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 03/28/2014 05:02 PM, Christoffer Dall wrote:
> > On Fri, Mar 28, 2014 at 04:08:52PM -0400, Michael Casadevall
> > wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>
> >>
> >>
> >> On 03/28/2014 03:47 PM, Christoffer Dall wrote:
> >>> On Fri, Mar 28, 2014 at 03:38:28PM -0400, Michael Casadevall
> >>> wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>>
> >>>>
> >>>>
> >>>> On 03/28/2014 02:09 PM, Christoffer Dall wrote:
> >>>>> On Fri, Mar 28, 2014 at 04:26:59AM -0400, Michael
> >>>>> Casadevall wrote:
> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>>>>
> >>>>>> As I've made a fair bit of headway since LinaroConnect,
> >>>>>> I wanted to drop a line on my current progress with
> >>>>>> porting TianoCore to KVM
> >>>>>>
> >>>>>> Summary (tl;dr version):
> >>>>>>
> >>>>>> KVM can start TianoCore, and boot all the way to shell,
> >>>>>> and access HDDs via VirtioBlk. We can start grub and
> >>>>>> successfully retrieve files from ext partitions, load a
> >>>>>> device tree, and start the kernel. The kernel runs
> >>>>>> through most of the EFI stub, but falls over during
> >>>>>> ExitBootServices()
> >>>>>
> >>>>> Thanks for providing this status!
> >>>>>
> >>>>>>
> >>>>>> Long Version:
> >>>>>>
> >>>>>> So, after much blood sweat and tears, we're finally at
> >>>>>> the point of trying to actually start a kernel, though
> >>>>>> this (for the moment) remains an elusive goal. The
> >>>>>> current problem is that once we call EBS(), we get an
> >>>>>> exception from EFI with no Image information, which means
> >>>>>> the exception handler doesn't know where it came from.
> >>>>>> After several seconds, we get a second exception from
> >>>>>> within DxeCore, and then EFI falls over.
> >>>>>>
> >>>>>> Debugging EFI is difficult and error prone, combined with
> >>>>>> limited debug facilities from the gdb-stub in QEMU (no
> >>>>>> breakpoints), and no decent way to load all of EFI
> >>>>>> itself (you have to run add-symbol-file manually with the
> >>>>>> output of commands printed on the console; supposedly its
> >>>>>> possible to generate a giant GdbSyms.dll file to import
> >>>>>> in a single go, but I haven't succeeded at this). This is
> >>>>>> further complicated that it appears we're asserting
> >>>>>> somewhere in a driver, and short of adding printfs to
> >>>>>> *every* driver, its impossible to know which is
> >>>>>> asseting.
> >>>>>
> >>>>> Maybe it's worth adding a hack-support-gdb-in-kvm
> >>>>> implementation for this. If we go down this road, I can
> >>>>> probably find time to help you out there.
> >>>>>
> >>>>> Can you do some scripting to replace assert statements with
> >>>>> "{ print("%s:%d\n", __FILE__, __LINE__); orig_assert(); }"
> >>>>> type hack?
> >>>>>
> >>>>
> >>>> That's probably a decent idea if I can find where ASSERT()
> >>>> is defined. I'll try that in a bit.
> >>>>
> >>>>>>
> >>>>>> Previous attempts to debug assets shows that EFI does
> >>>>>> "odd" things to the stack when we hit an exception,
> >>>>>> making walking it with GDB impossible. I need to figure
> >>>>>> out what madness EFI does with my SP so I can get the
> >>>>>> entire stack on an explosion, but this remains at best
> >>>>>> hopeful thinking.
> >>>>>
> >>>>> This sounds very strange - could it be that because you
> >>>>> take an exception, you use a SP from a different mode and
> >>>>> everything just messes up?
> >>>>>
> >>>>
> >>>> This could be GDB just being unhappy. I've had issues
> >>>> walking the stack in KVM in general, but even if I walk the
> >>>> stack by hand, I don't see a pointer to the next frame when
> >>>> we're in an exception. To my knowledge, UEFI uses the
> >>>> standard AArch64 C ABI, but this might be a faulty exception
> >>>> on my part.
> >>>>
> >>>>>>
> >>>>>> Further complicating things is that during EBS, my print
> >>>>>> debugging goes away. I might just cheat and roll a
> >>>>>> simple assembly function to bang out messages through
> >>>>>> serial without calling anything else. Ugly as sin, but
> >>>>>> this should let me get useful debug output through the
> >>>>>> EBS framework. Complicating matters is that I need to
> >>>>>> locate each and all EBS() event functions, which are
> >>>>>> spread *everywhere* in TianoCore, and then debug them
> >>>>>> each individually.
> >>>>>
> >>>>> I'm a little confused no knowing UEFI, is EBS() not a
> >>>>> single function and what does it matter that it's called
> >>>>> from multiple places?
> >>>>>
> >>>>
> >>>> So, drivers and applications can enlist to get notification
> >>>> of when ExitBootServices are called. This pushes a pointer to
> >>>> a function into an array when is then iterated through and
> >>>> this pointer is then called so drivers can unregister
> >>>> themselves from boot services, etc.
> >>>>
> >>>> Complicating the issue is I can't use printf once
> >>>> GetMemoryMap() is called without breaking EBS() (I think this
> >>>> is a bug in UEFI, leif, 2 cents?, but I think I can twiddle
> >>>> the serial port directly without breaking shit.
> >>>
> >>> yeah, just writing to the pl011 out should be trivial, or add
> >>> an hvc temporary hack to KVM, I've done things like that when
> >>> originally debugging kernel boot under KVM.
> >>>
> >>
> >> Just for the record, hvc?
> >>
> >
> > Hypervisor Call, 'HVC' is the instruction that causes a trap to
> > KVM, so you could do "mov r1, #0x41; mov r0, #0xff42; hvc #0;" to
> > invent a hypercall on number 0xff42 meaning "do print somewhere"
> > and print 'A'. That would be useful if you don't know what your
> > memory map is like and have no idea if you can even get to your
> > pl011 registers, but if know the address of that, it may be much
> > easier to just hardcode that.
> >
> >>>>
> >>>> Having slept on it, its probably easy to print out the
> >>>> pointers as we go through them, so I can get an idea of whats
> >>>> listening for EBS and try and narrow down my list of
> >>>> candidates.
> >>>>
> >>>
> >>> yes, add a function that side-steps all the UEFI-weirdness
> >>> (should be a few lines static function) that can print the
> >>> pointers of the functions you're calling.
> >>>
> >>
> >> Biggest issue is now binutils doesn't like PE?AArch64 files
> >> (addr2line and friends don't work) but I think I can muddle
> >> through it. There are tricks at this point I can use if I have a
> >> pointer to get an idea where UEFI is.
> >>
> >>>>>>
> >>>>>> I'm open to ideas on how best to accomplish this.
> >>>>>>
> >>>>>> On a larger scale, there are a couple of other bugs and
> >>>>>> odds and ends which currently affect us:
> >>>>>>
> >>>>>> * wfi doesn't work
> >>>>>>
> >>>>>> THis is probably the biggest w.r.t. to functionality
> >>>>>> that should work, but doesn't. The EFI event loop is
> >>>>>> built on checking the timer, then calling wfi to check
> >>>>>> the timer later. The problem here is we call wfi ... and
> >>>>>> UEFI never comes back despite events firing (I can put
> >>>>>> print code in the interrupt handler to confirm this).
> >>>>>> This may be related to the VGIC errors I get running kvm
> >>>>>> under foundation, but haven't taken the time to properly
> >>>>>> nail down the bug here.
> >>>>>
> >>>>> So if I understand it, the expected sequence of events
> >>>>> are:
> >>>>>
> >>>>> 1. check timer (arch timer counter?) 2. WFI 3. virtual
> >>>>> arch timer interrupt, causes wake-up from WFI 4. go to 1->
> >>>>>
> >>>>> But you seem to get stuck at (2)?
> >>>>>
> >>>>
> >>>> Exactly.
> >>>>
> >>>>> When you say "print code in the interrupt handler" is that
> >>>>> the UEFI interrupt handler? In that case, you do wake up
> >>>>> from the WFI...?
> >>>>>
> >>>>
> >>>> I put a DEBUG print line in the Timer interrupt handler,
> >>>> which prints out a message every tick letting me know the
> >>>> timer was working. When we call wfi, the timer ticks still
> >>>> show up (and I can see them through vgic with debugging there
> >>>> enabled)
> >>>>
> >>>
> >>> Which timer interrupt handler? The UEFI one?
> >>>
> >>> If you get an interrupt for the timer in UEFI, then your WFIs
> >>> are not hanging, the VCPU actually resumes. Assuming you
> >>> receive the interrupts on the same CPU that did the WFI.
> >>>
> >>
> >> We're running uni-proc as that's all KVM supports ATM. What
> >> happens is we wfi, the interrupt fires, the interrupt handler
> >> fires, and we remain at the wfi.
> >>
> >
> > again, which interrupt handler?
> >
> > If the one in UEFI, it sounds like you're problem is not that
> > you're stuck at WFI, but that you re-execute WFI.
> >
>
> The one in EFI, and I suspect thats the case, we re-execute wfi.
if you run the interrupt handler you are not stuck in wfi, but
re-execute it, and it's your software wait condition which is the
problem - likely related to the missing rtc?
-Christoffer
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
