| Message ID | 53E3EFCA.2050604@redhat.com |
|---|---|
| State | New |
| Headers | show |
Hi Laszlo, I don't understand. When I break into UEFI shell, and run 'dh', I can see device driver handles. This means that 'BdsConnectAllDrivers' was called and that in turn called 'CoreConnectController'. Now the question is, if a driver generates a child handle, 'CoreConnectController' should be called on that child handle. From the code, I see that is only possible if protocol has not been opened by child handle. What do you think ? Date: Thu, 7 Aug 2014 23:29:46 +0200 From: lersek@redhat.com To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] UEFI Shell Command "ifconfig" Error On 08/07/14 23:05, Chris Cuthbert wrote: > This is ARM from edk2. All open source, nothing proprietary. Ah. Yes. I recall that. Actually I have a downstream hack that is related. I'll attach it just as illustration (the other tree patches just increase the convenience). The point is (IIRC!) that ARM BDS does not call BdsConnectAllDrivers() before reaching the boot menu. I guess that's probably the issue. In my case I wanted to auto-generate a boot option (for the boot menu) for whatever disk partition that looked like an EFI System Partition. The disk in question that I had was a virtio-blk disk, and the patch didn't work initially. The reason was that at that point the disk had not been connected yet. So, IMHO you can solve this by inserting a call to BdsConnectAllDrivers() in a strategic point. You should probably find that point yourself; for me it was DefineDefaultBootEntries(). (Note: I haven't tested this patch in a while, but the above was certainly the case when I last run it.) Laszlo ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
Hi Laszlo,
This is what is happening. When I boot the system and run 'devtree' shell command, I get the following. Parent @7A and child @7B.
Ctrl[33] PciRoot(0x2)
Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0)
Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0)
Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)
Ctrl[7B] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(121212121212,0x1)
Then I issue 'disconnect 7A' command and see the following.
Ctrl[33] PciRoot(0x2)
Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0)
Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0)
Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)
Then I issue 'connect 7A' and see the following from 'devtree' command.
Ctrl[33] PciRoot(0x2)
Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0)
Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0)
Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)
Ctrl[89] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(121212121212,0x1)
Now if I issue 'connect 89', then the MNP Support function will get called to bind the MNP driver to the SNP protocol produced by '89'.
Looks to me, that connecting the parent does not result in child handles being connected recursively. This can happen if the child counting loop that is looking for protocol opened by child does not see the protocol opened by child.
Narinder Dhillon
From: nd6969@hotmail.com
To: edk2-devel@lists.sourceforge.net
Date: Thu, 7 Aug 2014 22:08:46 +0000
Subject: Re: [edk2] UEFI Shell Command "ifconfig" Error
Hi Laszlo,
I don't understand. When I break into UEFI shell, and run 'dh', I can see device driver handles. This means that 'BdsConnectAllDrivers' was called and that in turn called 'CoreConnectController'. Now the question is, if a driver generates a child handle, 'CoreConnectController' should be called on that child handle. From the code, I see that is only possible if protocol has not been opened by child handle.
What do you think ?
Date: Thu, 7 Aug 2014 23:29:46 +0200
From: lersek@redhat.com
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] UEFI Shell Command "ifconfig" Error
On 08/07/14 23:05, Chris Cuthbert wrote:
> This is ARM from edk2. All open source, nothing proprietary.
Ah. Yes. I recall that. Actually I have a downstream hack that is
related. I'll attach it just as illustration (the other tree patches
just increase the convenience). The point is (IIRC!) that ARM BDS does
not call BdsConnectAllDrivers() before reaching the boot menu. I guess
that's probably the issue.
In my case I wanted to auto-generate a boot option (for the boot menu)
for whatever disk partition that looked like an EFI System Partition.
The disk in question that I had was a virtio-blk disk, and the patch
didn't work initially. The reason was that at that point the disk had
not been connected yet. So, IMHO you can solve this by inserting a call
to BdsConnectAllDrivers() in a strategic point. You should probably find
that point yourself; for me it was DefineDefaultBootEntries().
(Note: I haven't tested this patch in a while, but the above was
certainly the case when I last run it.)
Laszlo
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
On Aug 7, 2014, at 3:08 PM, Chris Cuthbert <nd6969@hotmail.com> wrote: > Hi Laszlo, > > I don't understand. When I break into UEFI shell, and run 'dh', I can see device driver handles. This means that 'BdsConnectAllDrivers' was called and that in turn called 'CoreConnectController'. Now the question is, if a driver generates a child handle, 'CoreConnectController' should be called on that child handle. From the code, I see that is only possible if protocol has not been opened by child handle. > What do you think ? > I can’t remember the behavior of the new shell, but the old shell would connect devices as it was loaded so the state before the shell loaded, and after the shell loaded where not the same. Thanks, Andrew Fish > > Date: Thu, 7 Aug 2014 23:29:46 +0200 > From: lersek@redhat.com > To: edk2-devel@lists.sourceforge.net > Subject: Re: [edk2] UEFI Shell Command "ifconfig" Error > > On 08/07/14 23:05, Chris Cuthbert wrote: > > This is ARM from edk2. All open source, nothing proprietary. > > Ah. Yes. I recall that. Actually I have a downstream hack that is > related. I'll attach it just as illustration (the other tree patches > just increase the convenience). The point is (IIRC!) that ARM BDS does > not call BdsConnectAllDrivers() before reaching the boot menu. I guess > that's probably the issue. > > In my case I wanted to auto-generate a boot option (for the boot menu) > for whatever disk partition that looked like an EFI System Partition. > The disk in question that I had was a virtio-blk disk, and the patch > didn't work initially. The reason was that at that point the disk had > not been connected yet. So, IMHO you can solve this by inserting a call > to BdsConnectAllDrivers() in a strategic point. You should probably find > that point yourself; for me it was DefineDefaultBootEntries(). > > (Note: I haven't tested this patch in a while, but the above was > certainly the case when I last run it.) > > Laszlo > > > ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk_______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
Andrew is correct. There is a parameter on “load” to prevent connecting a newly loaded driver. Note: another driver may already have grabbed the interface that your driver wants to open (in the case up a upper level driver especially), and you’d need to disconnect that other driver. -Jaben From: Andrew Fish [mailto:afish@apple.com] Sent: Thursday, August 07, 2014 3:44 PM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] UEFI Shell Command "ifconfig" Error On Aug 7, 2014, at 3:08 PM, Chris Cuthbert <nd6969@hotmail.com<mailto:nd6969@hotmail.com>> wrote: Hi Laszlo, I don't understand. When I break into UEFI shell, and run 'dh', I can see device driver handles. This means that 'BdsConnectAllDrivers' was called and that in turn called 'CoreConnectController'. Now the question is, if a driver generates a child handle, 'CoreConnectController' should be called on that child handle. From the code, I see that is only possible if protocol has not been opened by child handle. What do you think ? I can’t remember the behavior of the new shell, but the old shell would connect devices as it was loaded so the state before the shell loaded, and after the shell loaded where not the same. Thanks, Andrew Fish Date: Thu, 7 Aug 2014 23:29:46 +0200 From: lersek@redhat.com<mailto:lersek@redhat.com> To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net> Subject: Re: [edk2] UEFI Shell Command "ifconfig" Error On 08/07/14 23:05, Chris Cuthbert wrote: > This is ARM from edk2. All open source, nothing proprietary. Ah. Yes. I recall that. Actually I have a downstream hack that is related. I'll attach it just as illustration (the other tree patches just increase the convenience). The point is (IIRC!) that ARM BDS does not call BdsConnectAllDrivers() before reaching the boot menu. I guess that's probably the issue. In my case I wanted to auto-generate a boot option (for the boot menu) for whatever disk partition that looked like an EFI System Partition. The disk in question that I had was a virtio-blk disk, and the patch didn't work initially. The reason was that at that point the disk had not been connected yet. So, IMHO you can solve this by inserting a call to BdsConnectAllDrivers() in a strategic point. You should probably find that point yourself; for me it was DefineDefaultBootEntries(). (Note: I haven't tested this patch in a while, but the above was certainly the case when I last run it.) Laszlo ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
On 08/08/14 00:08, Chris Cuthbert wrote: > Hi Laszlo, > > I don't understand. When I break into UEFI shell, and run 'dh', I can > see device driver handles. This means that 'BdsConnectAllDrivers' was > called and that in turn called 'CoreConnectController'. I disagree. Just because *something* connected the PCI controller in question to your driver, non-recursively, it doesn't necessarily follow that it was BdsConnectAllDrivers(). Several functions exist that do selective connecting. > Now the question > is, if a driver generates a child handle, 'CoreConnectController' should > be called on that child handle. If recursive connection was requested. For example, the BdsConnectAndUpdateDevicePath() [ArmPkg/Library/BdsLib/BdsFilePath.c] does not request recursive connecting. > From the code, I see that is only > possible if protocol has not been opened by child handle. > What do you think ? If recursive connection was requested, then yes, it could be broken by not having the BY_CHILD_CONTROLLER reference in place. Laszlo ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
On 08/08/14 00:39, Chris Cuthbert wrote: > Hi Laszlo, > > This is what is happening. When I boot the system and run 'devtree' > shell command, I get the following. Parent @7A and child @7B. > > Ctrl[33] PciRoot(0x2) > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > Ctrl[7B] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(121212121212,0x1) > > Then I issue 'disconnect 7A' command and see the following. > > Ctrl[33] PciRoot(0x2) > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > > Then I issue 'connect 7A' and see the following from 'devtree' command. > > Ctrl[33] PciRoot(0x2) > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > Ctrl[89] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(121212121212,0x1) > > Now if I issue 'connect 89', then the MNP Support function will get > called to bind the MNP driver to the SNP protocol produced by '89'. > > Looks to me, that connecting the parent does not result in child handles > being connected recursively. Of course they won't be connected recursively if you don't request recursive connecting! I specifically emphasized the -r (DASH R) option of the "connect" shell command before. I referenced the -r option two times. Please pay attention. > This can happen if the child counting loop > that is looking for protocol opened by child does not see the protocol > opened by child. It can also happen if that loop is not reached at all because you pass Recursive=FALSE to CoreConnectController(). Laszlo ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
Hi Laszlo, The '-r' option only works for all drivers and not for individual drivers. > Date: Fri, 8 Aug 2014 01:02:12 +0200 > From: lersek@redhat.com > To: edk2-devel@lists.sourceforge.net > Subject: Re: [edk2] UEFI Shell Command "ifconfig" Error > > On 08/08/14 00:39, Chris Cuthbert wrote: > > Hi Laszlo, > > > > This is what is happening. When I boot the system and run 'devtree' > > shell command, I get the following. Parent @7A and child @7B. > > > > Ctrl[33] PciRoot(0x2) > > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > > Ctrl[7B] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(121212121212,0x1) > > > > Then I issue 'disconnect 7A' command and see the following. > > > > Ctrl[33] PciRoot(0x2) > > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > > > > Then I issue 'connect 7A' and see the following from 'devtree' command. > > > > Ctrl[33] PciRoot(0x2) > > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > > Ctrl[89] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(121212121212,0x1) > > > > Now if I issue 'connect 89', then the MNP Support function will get > > called to bind the MNP driver to the SNP protocol produced by '89'. > > > > Looks to me, that connecting the parent does not result in child handles > > being connected recursively. > > Of course they won't be connected recursively if you don't request > recursive connecting! I specifically emphasized the -r (DASH R) option > of the "connect" shell command before. I referenced the -r option two > times. Please pay attention. > > > This can happen if the child counting loop > > that is looking for protocol opened by child does not see the protocol > > opened by child. > > It can also happen if that loop is not reached at all because you pass > Recursive=FALSE to CoreConnectController(). > > Laszlo > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
On Aug 7, 2014, at 4:37 PM, Chris Cuthbert <nd6969@hotmail.com> wrote: > Hi Laszlo, > > The '-r' option only works for all drivers and not for individual drivers. > I think the -r is down stream of the handle you are connecting. So if you don’t pass DeviceHandle then it is a connect all. If not it is down stream of DeviceHandle. Thanks, Andrew Fish > > > Date: Fri, 8 Aug 2014 01:02:12 +0200 > > From: lersek@redhat.com > > To: edk2-devel@lists.sourceforge.net > > Subject: Re: [edk2] UEFI Shell Command "ifconfig" Error > > > > On 08/08/14 00:39, Chris Cuthbert wrote: > > > Hi Laszlo, > > > > > > This is what is happening. When I boot the system and run 'devtree' > > > shell command, I get the following. Parent @7A and child @7B. > > > > > > Ctrl[33] PciRoot(0x2) > > > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > > > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > > > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > > > Ctrl[7B] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(121212121212,0x1) > > > > > > Then I issue 'disconnect 7A' command and see the following. > > > > > > Ctrl[33] PciRoot(0x2) > > > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > > > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > > > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > > > > > > Then I issue 'connect 7A' and see the following from 'devtree' command. > > > > > > Ctrl[33] PciRoot(0x2) > > > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > > > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > > > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > > > Ctrl[89] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(121212121212,0x1) > > > > > > Now if I issue 'connect 89', then the MNP Support function will get > > > called to bind the MNP driver to the SNP protocol produced by '89'. > > > > > > Looks to me, that connecting the parent does not result in child handles > > > being connected recursively. > > > > Of course they won't be connected recursively if you don't request > > recursive connecting! I specifically emphasized the -r (DASH R) option > > of the "connect" shell command before. I referenced the -r option two > > times. Please pay attention. > > > > > This can happen if the child counting loop > > > that is looking for protocol opened by child does not see the protocol > > > opened by child. > > > > It can also happen if that loop is not reached at all because you pass > > Recursive=FALSE to CoreConnectController(). > > > > Laszlo > > > > ------------------------------------------------------------------------------ > > Infragistics Professional > > Build stunning WinForms apps today! > > Reboot your WinForms applications with our WinForms controls. > > Build a bridge from your legacy apps to the future. > > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/edk2-devel > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk_______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
Hi Andrew, Sorry, is this what you are saying ? Shell> disconnect 7a -r Error. Too many arguments specified. Shell> From: afish@apple.com Date: Thu, 7 Aug 2014 16:43:55 -0700 To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] UEFI Shell Command "ifconfig" Error On Aug 7, 2014, at 4:37 PM, Chris Cuthbert <nd6969@hotmail.com> wrote:Hi Laszlo, The '-r' option only works for all drivers and not for individual drivers. I think the -r is down stream of the handle you are connecting. So if you don’t pass DeviceHandle then it is a connect all. If not it is down stream of DeviceHandle. Thanks, Andrew Fish > Date: Fri, 8 Aug 2014 01:02:12 +0200 > From: lersek@redhat.com > To: edk2-devel@lists.sourceforge.net > Subject: Re: [edk2] UEFI Shell Command "ifconfig" Error > > On 08/08/14 00:39, Chris Cuthbert wrote: > > Hi Laszlo, > > > > This is what is happening. When I boot the system and run 'devtree' > > shell command, I get the following. Parent @7A and child @7B. > > > > Ctrl[33] PciRoot(0x2) > > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > > Ctrl[7B] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(121212121212,0x1) > > > > Then I issue 'disconnect 7A' command and see the following. > > > > Ctrl[33] PciRoot(0x2) > > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > > > > Then I issue 'connect 7A' and see the following from 'devtree' command. > > > > Ctrl[33] PciRoot(0x2) > > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > > Ctrl[89] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(121212121212,0x1) > > > > Now if I issue 'connect 89', then the MNP Support function will get > > called to bind the MNP driver to the SNP protocol produced by '89'. > > > > Looks to me, that connecting the parent does not result in child handles > > being connected recursively. > > Of course they won't be connected recursively if you don't request > recursive connecting! I specifically emphasized the -r (DASH R) option > of the "connect" shell command before. I referenced the -r option two > times. Please pay attention. > > > This can happen if the child counting loop > > that is looking for protocol opened by child does not see the protocol > > opened by child. > > It can also happen if that loop is not reached at all because you pass > Recursive=FALSE to CoreConnectController(). > > Laszlo > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
On Aug 7, 2014, at 4:49 PM, Chris Cuthbert <nd6969@hotmail.com> wrote: > Hi Andrew, > > Sorry, is this what you are saying ? > > Shell> disconnect 7a -r > Error. Too many arguments specified. > Shell> > It helps to look at the APIs https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Uefi/UefiSpec.h typedef EFI_STATUS (EFIAPI *EFI_CONNECT_CONTROLLER)( IN EFI_HANDLE ControllerHandle, IN EFI_HANDLE *DriverImageHandle, OPTIONAL IN EFI_DEVICE_PATH_PROTOCOL *RemainingDevicePath, OPTIONAL IN BOOLEAN Recursive ); typedef EFI_STATUS (EFIAPI *EFI_DISCONNECT_CONTROLLER)( IN EFI_HANDLE ControllerHandle, IN EFI_HANDLE DriverImageHandle, OPTIONAL IN EFI_HANDLE ChildHandle OPTIONAL ); So when you disconnect you have to disconnect all the children, before you disconnect your driver. When you connect you have the option or recursively connecting the children or not. This is why the connect/disconnect commands are not symmetric. Thanks, Andrew Fish > > From: afish@apple.com > Date: Thu, 7 Aug 2014 16:43:55 -0700 > To: edk2-devel@lists.sourceforge.net > Subject: Re: [edk2] UEFI Shell Command "ifconfig" Error > > > On Aug 7, 2014, at 4:37 PM, Chris Cuthbert <nd6969@hotmail.com> wrote: > > Hi Laszlo, > > The '-r' option only works for all drivers and not for individual drivers. > > > I think the -r is down stream of the handle you are connecting. So if you don’t pass DeviceHandle then it is a connect all. If not it is down stream of DeviceHandle. > > Thanks, > > Andrew Fish > > > > Date: Fri, 8 Aug 2014 01:02:12 +0200 > > From: lersek@redhat.com > > To: edk2-devel@lists.sourceforge.net > > Subject: Re: [edk2] UEFI Shell Command "ifconfig" Error > > > > On 08/08/14 00:39, Chris Cuthbert wrote: > > > Hi Laszlo, > > > > > > This is what is happening. When I boot the system and run 'devtree' > > > shell command, I get the following. Parent @7A and child @7B. > > > > > > Ctrl[33] PciRoot(0x2) > > > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > > > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > > > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > > > Ctrl[7B] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(121212121212,0x1) > > > > > > Then I issue 'disconnect 7A' command and see the following. > > > > > > Ctrl[33] PciRoot(0x2) > > > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > > > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > > > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > > > > > > Then I issue 'connect 7A' and see the following from 'devtree' command. > > > > > > Ctrl[33] PciRoot(0x2) > > > Ctrl[78] PciRoot(0x2)/Pci(0x1,0x0) > > > Ctrl[79] PciRoot(0x2)/Pci(0x2,0x0) > > > Ctrl[7A] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0) > > > Ctrl[89] PciRoot(0x2)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(121212121212,0x1) > > > > > > Now if I issue 'connect 89', then the MNP Support function will get > > > called to bind the MNP driver to the SNP protocol produced by '89'. > > > > > > Looks to me, that connecting the parent does not result in child handles > > > being connected recursively. > > > > Of course they won't be connected recursively if you don't request > > recursive connecting! I specifically emphasized the -r (DASH R) option > > of the "connect" shell command before. I referenced the -r option two > > times. Please pay attention. > > > > > This can happen if the child counting loop > > > that is looking for protocol opened by child does not see the protocol > > > opened by child. > > > > It can also happen if that loop is not reached at all because you pass > > Recursive=FALSE to CoreConnectController(). > > > > Laszlo > > > > ------------------------------------------------------------------------------ > > Infragistics Professional > > Build stunning WinForms apps today! > > Reboot your WinForms applications with our WinForms controls. > > Build a bridge from your legacy apps to the future. > > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/edk2-devel > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk_______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > > ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk_______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
From be53ae2b975685a4a6f665e737fffe5460dc2ce7 Mon Sep 17 00:00:00 2001 From: Laszlo Ersek <lersek@redhat.com> Date: Thu, 9 Jan 2014 01:37:44 +0100 Subject: [PATCH 4/4] ArmPlatformPkg: FVP: set boot type to EfiApp, auto-detect boot path Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc index 7cc4e27..ea20fcc 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc @@ -164,12 +164,11 @@ # ARM OS Loader # # Versatile Express machine type (ARM VERSATILE EXPRESS = 2272) required for ARM Linux: - gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|L"Linux from SemiHosting" - gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/Image" - gArmPlatformTokenSpaceGuid.PcdDefaultBootInitrdPath|L"VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/filesystem.cpio.gz" - gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|"console=ttyAMA0 earlyprintk=pl011,0x1c090000 debug user_debug=31 loglevel=9" - gArmPlatformTokenSpaceGuid.PcdDefaultBootType|2 - gArmPlatformTokenSpaceGuid.PcdFdtDevicePath|L"VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/fdt.dtb" + gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|L"Linux from first ESP" + gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"" + gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|"" + gArmPlatformTokenSpaceGuid.PcdDefaultBootType|0 + gArmPlatformTokenSpaceGuid.PcdFdtDevicePath|L"" # Use the serial console (ConIn & ConOut) and the Graphic driver (ConOut) gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenPcAnsi();VenHw(407B4008-BF5B-11DF-9547-CF16E0D72085)" -- 1.8.3.1
On 08/07/14 23:05, Chris Cuthbert wrote: > This is ARM from edk2. All open source, nothing proprietary. Ah. Yes. I recall that. Actually I have a downstream hack that is related. I'll attach it just as illustration (the other tree patches just increase the convenience). The point is (IIRC!) that ARM BDS does not call BdsConnectAllDrivers() before reaching the boot menu. I guess that's probably the issue. In my case I wanted to auto-generate a boot option (for the boot menu) for whatever disk partition that looked like an EFI System Partition. The disk in question that I had was a virtio-blk disk, and the patch didn't work initially. The reason was that at that point the disk had not been connected yet. So, IMHO you can solve this by inserting a call to BdsConnectAllDrivers() in a strategic point. You should probably find that point yourself; for me it was DefineDefaultBootEntries(). (Note: I haven't tested this patch in a while, but the above was certainly the case when I last run it.) Laszlo ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk