* [U-Boot] [PATCH 0/2] x86: Convert all boards to use MMC to driver model @ 2017-04-10 0:38 Simon Glass 2017-04-10 0:38 ` [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 Simon Glass 2017-04-10 0:38 ` [U-Boot] [PATCH 2/2] x86: Convert MMC to driver model Simon Glass 0 siblings, 2 replies; 22+ messages in thread From: Simon Glass @ 2017-04-10 0:38 UTC (permalink / raw) To: u-boot This serial converts x86 boards to use MMC for driver model. It has to disable SCSI to make this work, for now. Once SCSI is sorted out, we can apply the patch. Simon Glass (2): WIP: Disable SCSI on x86 x86: Convert MMC to driver model arch/Kconfig | 1 + arch/x86/cpu/baytrail/valleyview.c | 12 ------ arch/x86/cpu/quark/quark.c | 10 ----- arch/x86/cpu/queensbay/Makefile | 2 +- arch/x86/cpu/queensbay/topcliff.c | 20 --------- drivers/mmc/pci_mmc.c | 86 ++++++++++++++++++++++++++------------ include/configs/x86-common.h | 6 ++- include/mmc.h | 12 ------ 8 files changed, 66 insertions(+), 83 deletions(-) delete mode 100644 arch/x86/cpu/queensbay/topcliff.c -- 2.12.2.715.g7642488e1d-goog ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-04-10 0:38 [U-Boot] [PATCH 0/2] x86: Convert all boards to use MMC to driver model Simon Glass @ 2017-04-10 0:38 ` Simon Glass 2017-05-08 7:05 ` Bin Meng 2017-04-10 0:38 ` [U-Boot] [PATCH 2/2] x86: Convert MMC to driver model Simon Glass 1 sibling, 1 reply; 22+ messages in thread From: Simon Glass @ 2017-04-10 0:38 UTC (permalink / raw) To: u-boot This is not to be applied. It is needed to test using CONFIG_DM_MMC on x86 since SCSI is broken with this setup. Signed-off-by: Simon Glass <sjg@chromium.org> --- include/configs/x86-common.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h index f7796cf63f..67f19d4121 100644 --- a/include/configs/x86-common.h +++ b/include/configs/x86-common.h @@ -30,7 +30,7 @@ #define CONFIG_SYS_BOOTM_LEN (16 << 20) /* SATA AHCI storage */ - +#if 0 #define CONFIG_SCSI_AHCI #ifdef CONFIG_SCSI_AHCI #define CONFIG_LIBATA @@ -42,6 +42,7 @@ #define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \ CONFIG_SYS_SCSI_MAX_LUN) #endif +#endif /* Generic TPM interfaced through LPC bus */ #define CONFIG_TPM_TIS_BASE_ADDRESS 0xfed40000 @@ -82,8 +83,9 @@ #define CONFIG_CMD_IRQ #define CONFIG_CMD_PCI #define CONFIG_CMD_GETTIME +/* #define CONFIG_SCSI - +*/ #define CONFIG_CMD_ZBOOT #define CONFIG_BOOTARGS \ -- 2.12.2.715.g7642488e1d-goog ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-04-10 0:38 ` [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 Simon Glass @ 2017-05-08 7:05 ` Bin Meng 2017-05-13 1:11 ` Simon Glass 0 siblings, 1 reply; 22+ messages in thread From: Bin Meng @ 2017-05-08 7:05 UTC (permalink / raw) To: u-boot Hi Simon, On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> wrote: > This is not to be applied. It is needed to test using CONFIG_DM_MMC on x86 > since SCSI is broken with this setup. > > Signed-off-by: Simon Glass <sjg@chromium.org> > --- When you said "SCSI is broken with this setup", did you mean GP# exception when boot up with a hard disk like below? SCSI: Target spinup took 0 ms. SATA link 1 timeout. AHCI 0001.0300 32 slots 2 ports 3 Gbps 0x3 impl SATA mode flags: 64bit ncq stag pm led clo pio slum part sxs scanning bus for devices... General Protection EIP: 0010:[<46174204>] EFLAGS: 00010202 Original EIP :[<cab17204>] EAX: 00000000 EBX: 46174204 ECX: 00000000 EDX: 00000000 ESI: 7b347f80 EDI: 7b5c3fc8 EBP: 7b3481c4 ESP: 7b347f58 DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018 CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000600 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Stack: 0x7b347f98 : 0x20202020 0x7b347f94 : 0x20202020 0x7b347f90 : 0x00000000 0x7b347f8c : 0x0000003f 0x7b347f88 : 0x00000000 0x7b347f84 : 0x0010c837 0x7b347f80 : 0x3fff0c5a 0x7b347f7c : 0x7b585f7d 0x7b347f78 : 0x7b347f80 0x7b347f74 : 0x00000000 0x7b347f70 : 0x00000001 0x7b347f6c : 0x7b57b01d 0x7b347f68 : 0x7b5c3fc8 0x7b347f64 : 0x7b347f80 0x7b347f60 : 0x00000000 0x7b347f5c : 0x00000001 --->0x7b347f58 : 0x7b57cd1a 0x7b347f54 : 0x00010202 0x7b347f50 : 0x00000010 0x7b347f4c : 0x46174204 ### ERROR ### Please RESET the board ### [snip] Regards, Bin ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-05-08 7:05 ` Bin Meng @ 2017-05-13 1:11 ` Simon Glass 2017-05-17 0:42 ` Bin Meng 0 siblings, 1 reply; 22+ messages in thread From: Simon Glass @ 2017-05-13 1:11 UTC (permalink / raw) To: u-boot Hi Bin, On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: > Hi Simon, > > On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> wrote: >> This is not to be applied. It is needed to test using CONFIG_DM_MMC on x86 >> since SCSI is broken with this setup. >> >> Signed-off-by: Simon Glass <sjg@chromium.org> >> --- > > When you said "SCSI is broken with this setup", did you mean GP# > exception when boot up with a hard disk like below? Yes that's right. > > SCSI: Target spinup took 0 ms. > SATA link 1 timeout. > AHCI 0001.0300 32 slots 2 ports 3 Gbps 0x3 impl SATA mode > flags: 64bit ncq stag pm led clo pio slum part sxs > scanning bus for devices... > General Protection > EIP: 0010:[<46174204>] EFLAGS: 00010202 > Original EIP :[<cab17204>] > EAX: 00000000 EBX: 46174204 ECX: 00000000 EDX: 00000000 > ESI: 7b347f80 EDI: 7b5c3fc8 EBP: 7b3481c4 ESP: 7b347f58 > DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018 > CR0: 00000033 CR2: 00000000 CR3: 00000000 CR4: 00000600 > DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 > DR6: ffff0ff0 DR7: 00000400 > Stack: > 0x7b347f98 : 0x20202020 > 0x7b347f94 : 0x20202020 > 0x7b347f90 : 0x00000000 > 0x7b347f8c : 0x0000003f > 0x7b347f88 : 0x00000000 > 0x7b347f84 : 0x0010c837 > 0x7b347f80 : 0x3fff0c5a > 0x7b347f7c : 0x7b585f7d > 0x7b347f78 : 0x7b347f80 > 0x7b347f74 : 0x00000000 > 0x7b347f70 : 0x00000001 > 0x7b347f6c : 0x7b57b01d > 0x7b347f68 : 0x7b5c3fc8 > 0x7b347f64 : 0x7b347f80 > 0x7b347f60 : 0x00000000 > 0x7b347f5c : 0x00000001 > --->0x7b347f58 : 0x7b57cd1a > 0x7b347f54 : 0x00010202 > 0x7b347f50 : 0x00000010 > 0x7b347f4c : 0x46174204 > ### ERROR ### Please RESET the board ### > > > [snip] > > Regards, > Bin - Simon ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-05-13 1:11 ` Simon Glass @ 2017-05-17 0:42 ` Bin Meng 2017-06-01 7:27 ` Bin Meng 0 siblings, 1 reply; 22+ messages in thread From: Bin Meng @ 2017-05-17 0:42 UTC (permalink / raw) To: u-boot Hi Simon, On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> wrote: > Hi Bin, > > On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: >> Hi Simon, >> >> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> wrote: >>> This is not to be applied. It is needed to test using CONFIG_DM_MMC on x86 >>> since SCSI is broken with this setup. >>> >>> Signed-off-by: Simon Glass <sjg@chromium.org> >>> --- >> >> When you said "SCSI is broken with this setup", did you mean GP# >> exception when boot up with a hard disk like below? > > Yes that's right. > Do you plan to work on a patch soon? Regards, Bin ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-05-17 0:42 ` Bin Meng @ 2017-06-01 7:27 ` Bin Meng 2017-06-01 13:14 ` Simon Glass 0 siblings, 1 reply; 22+ messages in thread From: Bin Meng @ 2017-06-01 7:27 UTC (permalink / raw) To: u-boot Hi Simon, On Wed, May 17, 2017 at 8:42 AM, Bin Meng <bmeng.cn@gmail.com> wrote: > Hi Simon, > > On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> wrote: >> Hi Bin, >> >> On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: >>> Hi Simon, >>> >>> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> wrote: >>>> This is not to be applied. It is needed to test using CONFIG_DM_MMC on x86 >>>> since SCSI is broken with this setup. >>>> >>>> Signed-off-by: Simon Glass <sjg@chromium.org> >>>> --- >>> >>> When you said "SCSI is broken with this setup", did you mean GP# >>> exception when boot up with a hard disk like below? >> >> Yes that's right. >> > > Do you plan to work on a patch soon? > I tracked down the exception happens at part_test_efi()->block_dread() function: if (!ops->read) return -ENOSYS; Where ops points to nowhere, because underlying SATA device does not have a DM driver associated. Could you please fix this? Regards, Bin ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-06-01 7:27 ` Bin Meng @ 2017-06-01 13:14 ` Simon Glass 2017-06-01 23:04 ` Bin Meng 0 siblings, 1 reply; 22+ messages in thread From: Simon Glass @ 2017-06-01 13:14 UTC (permalink / raw) To: u-boot Hi Bin, On 1 June 2017 at 01:27, Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Simon, > > On Wed, May 17, 2017 at 8:42 AM, Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Simon, > > > > On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> wrote: > >> Hi Bin, > >> > >> On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: > >>> Hi Simon, > >>> > >>> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> wrote: > >>>> This is not to be applied. It is needed to test using CONFIG_DM_MMC on x86 > >>>> since SCSI is broken with this setup. > >>>> > >>>> Signed-off-by: Simon Glass <sjg@chromium.org> > >>>> --- > >>> > >>> When you said "SCSI is broken with this setup", did you mean GP# > >>> exception when boot up with a hard disk like below? > >> > >> Yes that's right. > >> > > > > Do you plan to work on a patch soon? > > > > I tracked down the exception happens at part_test_efi()->block_dread() function: > > if (!ops->read) > return -ENOSYS; > > Where ops points to nowhere, because underlying SATA device does not > have a DM driver associated. > > Could you please fix this? I've been hoping that someone else will take on this side of things, but perhaps I am optimistic. I'll see if I can take a look. Regards, Simon ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-06-01 13:14 ` Simon Glass @ 2017-06-01 23:04 ` Bin Meng 2017-06-09 12:27 ` Simon Glass 0 siblings, 1 reply; 22+ messages in thread From: Bin Meng @ 2017-06-01 23:04 UTC (permalink / raw) To: u-boot Hi Simon, On Thu, Jun 1, 2017 at 9:14 PM, Simon Glass <sjg@chromium.org> wrote: > Hi Bin, > > On 1 June 2017 at 01:27, Bin Meng <bmeng.cn@gmail.com> wrote: >> >> Hi Simon, >> >> On Wed, May 17, 2017 at 8:42 AM, Bin Meng <bmeng.cn@gmail.com> wrote: >> > Hi Simon, >> > >> > On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> wrote: >> >> Hi Bin, >> >> >> >> On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: >> >>> Hi Simon, >> >>> >> >>> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> wrote: >> >>>> This is not to be applied. It is needed to test using CONFIG_DM_MMC on x86 >> >>>> since SCSI is broken with this setup. >> >>>> >> >>>> Signed-off-by: Simon Glass <sjg@chromium.org> >> >>>> --- >> >>> >> >>> When you said "SCSI is broken with this setup", did you mean GP# >> >>> exception when boot up with a hard disk like below? >> >> >> >> Yes that's right. >> >> >> > >> > Do you plan to work on a patch soon? >> > >> >> I tracked down the exception happens at part_test_efi()->block_dread() function: >> >> if (!ops->read) >> return -ENOSYS; >> >> Where ops points to nowhere, because underlying SATA device does not >> have a DM driver associated. >> >> Could you please fix this? > > I've been hoping that someone else will take on this side of things, > but perhaps I am optimistic. I'll see if I can take a look. Thanks. I wanted to fix this myself however I have been busy on some other stuff. Regards, Bin ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-06-01 23:04 ` Bin Meng @ 2017-06-09 12:27 ` Simon Glass 2017-06-10 3:47 ` Bin Meng 0 siblings, 1 reply; 22+ messages in thread From: Simon Glass @ 2017-06-09 12:27 UTC (permalink / raw) To: u-boot Hi Bin, On 1 June 2017 at 17:04, Bin Meng <bmeng.cn@gmail.com> wrote: > Hi Simon, > > On Thu, Jun 1, 2017 at 9:14 PM, Simon Glass <sjg@chromium.org> wrote: >> Hi Bin, >> >> On 1 June 2017 at 01:27, Bin Meng <bmeng.cn@gmail.com> wrote: >>> >>> Hi Simon, >>> >>> On Wed, May 17, 2017 at 8:42 AM, Bin Meng <bmeng.cn@gmail.com> wrote: >>> > Hi Simon, >>> > >>> > On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> wrote: >>> >> Hi Bin, >>> >> >>> >> On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: >>> >>> Hi Simon, >>> >>> >>> >>> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> wrote: >>> >>>> This is not to be applied. It is needed to test using CONFIG_DM_MMC on x86 >>> >>>> since SCSI is broken with this setup. >>> >>>> >>> >>>> Signed-off-by: Simon Glass <sjg@chromium.org> >>> >>>> --- >>> >>> >>> >>> When you said "SCSI is broken with this setup", did you mean GP# >>> >>> exception when boot up with a hard disk like below? >>> >> >>> >> Yes that's right. >>> >> >>> > >>> > Do you plan to work on a patch soon? >>> > >>> >>> I tracked down the exception happens at part_test_efi()->block_dread() function: >>> >>> if (!ops->read) >>> return -ENOSYS; >>> >>> Where ops points to nowhere, because underlying SATA device does not >>> have a DM driver associated. >>> >>> Could you please fix this? >> >> I've been hoping that someone else will take on this side of things, >> but perhaps I am optimistic. I'll see if I can take a look. > > Thanks. I wanted to fix this myself however I have been busy on some > other stuff. I've sent a series which I think puts SCSI and SATA in a better position with respect to driver model. However even with that there is more work to do. Regards, Simon ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-06-09 12:27 ` Simon Glass @ 2017-06-10 3:47 ` Bin Meng 2017-06-12 3:53 ` Simon Glass 0 siblings, 1 reply; 22+ messages in thread From: Bin Meng @ 2017-06-10 3:47 UTC (permalink / raw) To: u-boot Hi Simon, On Fri, Jun 9, 2017 at 8:27 PM, Simon Glass <sjg@chromium.org> wrote: > Hi Bin, > > On 1 June 2017 at 17:04, Bin Meng <bmeng.cn@gmail.com> wrote: >> Hi Simon, >> >> On Thu, Jun 1, 2017 at 9:14 PM, Simon Glass <sjg@chromium.org> wrote: >>> Hi Bin, >>> >>> On 1 June 2017 at 01:27, Bin Meng <bmeng.cn@gmail.com> wrote: >>>> >>>> Hi Simon, >>>> >>>> On Wed, May 17, 2017 at 8:42 AM, Bin Meng <bmeng.cn@gmail.com> wrote: >>>> > Hi Simon, >>>> > >>>> > On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> wrote: >>>> >> Hi Bin, >>>> >> >>>> >> On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: >>>> >>> Hi Simon, >>>> >>> >>>> >>> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> wrote: >>>> >>>> This is not to be applied. It is needed to test using CONFIG_DM_MMC on x86 >>>> >>>> since SCSI is broken with this setup. >>>> >>>> >>>> >>>> Signed-off-by: Simon Glass <sjg@chromium.org> >>>> >>>> --- >>>> >>> >>>> >>> When you said "SCSI is broken with this setup", did you mean GP# >>>> >>> exception when boot up with a hard disk like below? >>>> >> >>>> >> Yes that's right. >>>> >> >>>> > >>>> > Do you plan to work on a patch soon? >>>> > >>>> >>>> I tracked down the exception happens at part_test_efi()->block_dread() function: >>>> >>>> if (!ops->read) >>>> return -ENOSYS; >>>> >>>> Where ops points to nowhere, because underlying SATA device does not >>>> have a DM driver associated. >>>> >>>> Could you please fix this? >>> >>> I've been hoping that someone else will take on this side of things, >>> but perhaps I am optimistic. I'll see if I can take a look. >> >> Thanks. I wanted to fix this myself however I have been busy on some >> other stuff. > > I've sent a series which I think puts SCSI and SATA in a better > position with respect to driver model. However even with that there is > more work to do. > Thanks for working on this! I will take a look. If we don't get enough time to sort out everything, we will have to revert previous MMC DM conversion patch and leave that to next release. Regards, Bin ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-06-10 3:47 ` Bin Meng @ 2017-06-12 3:53 ` Simon Glass 2017-06-24 10:29 ` Stefan Roese 0 siblings, 1 reply; 22+ messages in thread From: Simon Glass @ 2017-06-12 3:53 UTC (permalink / raw) To: u-boot Hi Bin, On 9 June 2017 at 21:47, Bin Meng <bmeng.cn@gmail.com> wrote: > Hi Simon, > > On Fri, Jun 9, 2017 at 8:27 PM, Simon Glass <sjg@chromium.org> wrote: >> Hi Bin, >> >> On 1 June 2017 at 17:04, Bin Meng <bmeng.cn@gmail.com> wrote: >>> Hi Simon, >>> >>> On Thu, Jun 1, 2017 at 9:14 PM, Simon Glass <sjg@chromium.org> wrote: >>>> Hi Bin, >>>> >>>> On 1 June 2017 at 01:27, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>> >>>>> Hi Simon, >>>>> >>>>> On Wed, May 17, 2017 at 8:42 AM, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>> > Hi Simon, >>>>> > >>>>> > On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> wrote: >>>>> >> Hi Bin, >>>>> >> >>>>> >> On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>> >>> Hi Simon, >>>>> >>> >>>>> >>> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> wrote: >>>>> >>>> This is not to be applied. It is needed to test using CONFIG_DM_MMC on x86 >>>>> >>>> since SCSI is broken with this setup. >>>>> >>>> >>>>> >>>> Signed-off-by: Simon Glass <sjg@chromium.org> >>>>> >>>> --- >>>>> >>> >>>>> >>> When you said "SCSI is broken with this setup", did you mean GP# >>>>> >>> exception when boot up with a hard disk like below? >>>>> >> >>>>> >> Yes that's right. >>>>> >> >>>>> > >>>>> > Do you plan to work on a patch soon? >>>>> > >>>>> >>>>> I tracked down the exception happens at part_test_efi()->block_dread() function: >>>>> >>>>> if (!ops->read) >>>>> return -ENOSYS; >>>>> >>>>> Where ops points to nowhere, because underlying SATA device does not >>>>> have a DM driver associated. >>>>> >>>>> Could you please fix this? >>>> >>>> I've been hoping that someone else will take on this side of things, >>>> but perhaps I am optimistic. I'll see if I can take a look. >>> >>> Thanks. I wanted to fix this myself however I have been busy on some >>> other stuff. >> >> I've sent a series which I think puts SCSI and SATA in a better >> position with respect to driver model. However even with that there is >> more work to do. >> > > Thanks for working on this! I will take a look. > > If we don't get enough time to sort out everything, we will have to > revert previous MMC DM conversion patch and leave that to next > release. Yes, let's see how it goes. I probably have time for one more spin if it is soon...but the last patch needs work. Regards, Simon ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-06-12 3:53 ` Simon Glass @ 2017-06-24 10:29 ` Stefan Roese 2017-06-24 12:08 ` Bin Meng 0 siblings, 1 reply; 22+ messages in thread From: Stefan Roese @ 2017-06-24 10:29 UTC (permalink / raw) To: u-boot Hi Simon, Hi Bin, On 12.06.2017 05:53, Simon Glass wrote: > Hi Bin, > > On 9 June 2017 at 21:47, Bin Meng <bmeng.cn@gmail.com> wrote: >> Hi Simon, >> >> On Fri, Jun 9, 2017 at 8:27 PM, Simon Glass <sjg@chromium.org> wrote: >>> Hi Bin, >>> >>> On 1 June 2017 at 17:04, Bin Meng <bmeng.cn@gmail.com> wrote: >>>> Hi Simon, >>>> >>>> On Thu, Jun 1, 2017 at 9:14 PM, Simon Glass <sjg@chromium.org> wrote: >>>>> Hi Bin, >>>>> >>>>> On 1 June 2017 at 01:27, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>> >>>>>> Hi Simon, >>>>>> >>>>>> On Wed, May 17, 2017 at 8:42 AM, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>> Hi Simon, >>>>>>> >>>>>>> On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> wrote: >>>>>>>> Hi Bin, >>>>>>>> >>>>>>>> On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>>> Hi Simon, >>>>>>>>> >>>>>>>>> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> wrote: >>>>>>>>>> This is not to be applied. It is needed to test using CONFIG_DM_MMC on x86 >>>>>>>>>> since SCSI is broken with this setup. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org> >>>>>>>>>> --- >>>>>>>>> >>>>>>>>> When you said "SCSI is broken with this setup", did you mean GP# >>>>>>>>> exception when boot up with a hard disk like below? >>>>>>>> >>>>>>>> Yes that's right. >>>>>>>> >>>>>>> >>>>>>> Do you plan to work on a patch soon? >>>>>>> >>>>>> >>>>>> I tracked down the exception happens at part_test_efi()->block_dread() function: >>>>>> >>>>>> if (!ops->read) >>>>>> return -ENOSYS; >>>>>> >>>>>> Where ops points to nowhere, because underlying SATA device does not >>>>>> have a DM driver associated. >>>>>> >>>>>> Could you please fix this? >>>>> >>>>> I've been hoping that someone else will take on this side of things, >>>>> but perhaps I am optimistic. I'll see if I can take a look. >>>> >>>> Thanks. I wanted to fix this myself however I have been busy on some >>>> other stuff. >>> >>> I've sent a series which I think puts SCSI and SATA in a better >>> position with respect to driver model. However even with that there is >>> more work to do. >>> >> >> Thanks for working on this! I will take a look. >> >> If we don't get enough time to sort out everything, we will have to >> revert previous MMC DM conversion patch and leave that to next >> release. > > Yes, let's see how it goes. I probably have time for one more spin if > it is soon...but the last patch needs work. As Andreas has pointed out here: https://lists.denx.de/pipermail/u-boot/2017-June/296337.html SCSI seems to be broken also on Armada 37xx (and perhaps other platforms as well). Is it correct to assume, that this x86 SCSI thread is about the same issue? I know that you are working on DM SCSI support, which is great of course. But do you have an idea, if and how this could be fixed for this upcoming release? Thanks, Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-06-24 10:29 ` Stefan Roese @ 2017-06-24 12:08 ` Bin Meng 2017-06-26 7:29 ` Stefan Roese 0 siblings, 1 reply; 22+ messages in thread From: Bin Meng @ 2017-06-24 12:08 UTC (permalink / raw) To: u-boot Hi Stefan, On Sat, Jun 24, 2017 at 6:29 PM, Stefan Roese <sr@denx.de> wrote: > Hi Simon, Hi Bin, > > > On 12.06.2017 05:53, Simon Glass wrote: >> >> Hi Bin, >> >> On 9 June 2017 at 21:47, Bin Meng <bmeng.cn@gmail.com> wrote: >>> >>> Hi Simon, >>> >>> On Fri, Jun 9, 2017 at 8:27 PM, Simon Glass <sjg@chromium.org> wrote: >>>> >>>> Hi Bin, >>>> >>>> On 1 June 2017 at 17:04, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>> >>>>> Hi Simon, >>>>> >>>>> On Thu, Jun 1, 2017 at 9:14 PM, Simon Glass <sjg@chromium.org> wrote: >>>>>> >>>>>> Hi Bin, >>>>>> >>>>>> On 1 June 2017 at 01:27, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> Hi Simon, >>>>>>> >>>>>>> On Wed, May 17, 2017 at 8:42 AM, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>> >>>>>>>> Hi Simon, >>>>>>>> >>>>>>>> On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Bin, >>>>>>>>> >>>>>>>>> On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> Hi Simon, >>>>>>>>>> >>>>>>>>>> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> This is not to be applied. It is needed to test using >>>>>>>>>>> CONFIG_DM_MMC on x86 >>>>>>>>>>> since SCSI is broken with this setup. >>>>>>>>>>> >>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org> >>>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> When you said "SCSI is broken with this setup", did you mean GP# >>>>>>>>>> exception when boot up with a hard disk like below? >>>>>>>>> >>>>>>>>> >>>>>>>>> Yes that's right. >>>>>>>>> >>>>>>>> >>>>>>>> Do you plan to work on a patch soon? >>>>>>>> >>>>>>> >>>>>>> I tracked down the exception happens at >>>>>>> part_test_efi()->block_dread() function: >>>>>>> >>>>>>> if (!ops->read) >>>>>>> return -ENOSYS; >>>>>>> >>>>>>> Where ops points to nowhere, because underlying SATA device does not >>>>>>> have a DM driver associated. >>>>>>> >>>>>>> Could you please fix this? >>>>>> >>>>>> >>>>>> I've been hoping that someone else will take on this side of things, >>>>>> but perhaps I am optimistic. I'll see if I can take a look. >>>>> >>>>> >>>>> Thanks. I wanted to fix this myself however I have been busy on some >>>>> other stuff. >>>> >>>> >>>> I've sent a series which I think puts SCSI and SATA in a better >>>> position with respect to driver model. However even with that there is >>>> more work to do. >>>> >>> >>> Thanks for working on this! I will take a look. >>> >>> If we don't get enough time to sort out everything, we will have to >>> revert previous MMC DM conversion patch and leave that to next >>> release. >> >> >> Yes, let's see how it goes. I probably have time for one more spin if >> it is soon...but the last patch needs work. > > > As Andreas has pointed out here: > > https://lists.denx.de/pipermail/u-boot/2017-June/296337.html > > SCSI seems to be broken also on Armada 37xx (and perhaps other > platforms as well). Is it correct to assume, that this x86 SCSI > thread is about the same issue? > > I know that you are working on DM SCSI support, which is great of > course. But do you have an idea, if and how this could be fixed for > this upcoming release? Simon already sent a series to convert SCSI to DM and applied to u-boot-dm. I also sent a series to fix some additional issues [1]. Can you or Andreas try on top of u-boot-dm plus my patches to see if the issue is fixed? [1] http://patchwork.ozlabs.org/patch/777312/ Regards, Bin ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-06-24 12:08 ` Bin Meng @ 2017-06-26 7:29 ` Stefan Roese 2017-06-26 9:11 ` Bin Meng 0 siblings, 1 reply; 22+ messages in thread From: Stefan Roese @ 2017-06-26 7:29 UTC (permalink / raw) To: u-boot Hi Bin, On 24.06.2017 14:08, Bin Meng wrote: > Hi Stefan, > > On Sat, Jun 24, 2017 at 6:29 PM, Stefan Roese <sr@denx.de> wrote: >> Hi Simon, Hi Bin, >> >> >> On 12.06.2017 05:53, Simon Glass wrote: >>> >>> Hi Bin, >>> >>> On 9 June 2017 at 21:47, Bin Meng <bmeng.cn@gmail.com> wrote: >>>> >>>> Hi Simon, >>>> >>>> On Fri, Jun 9, 2017 at 8:27 PM, Simon Glass <sjg@chromium.org> wrote: >>>>> >>>>> Hi Bin, >>>>> >>>>> On 1 June 2017 at 17:04, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>> >>>>>> Hi Simon, >>>>>> >>>>>> On Thu, Jun 1, 2017 at 9:14 PM, Simon Glass <sjg@chromium.org> wrote: >>>>>>> >>>>>>> Hi Bin, >>>>>>> >>>>>>> On 1 June 2017 at 01:27, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi Simon, >>>>>>>> >>>>>>>> On Wed, May 17, 2017 at 8:42 AM, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>>> >>>>>>>>> Hi Simon, >>>>>>>>> >>>>>>>>> On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Bin, >>>>>>>>>> >>>>>>>>>> On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Simon, >>>>>>>>>>> >>>>>>>>>>> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> This is not to be applied. It is needed to test using >>>>>>>>>>>> CONFIG_DM_MMC on x86 >>>>>>>>>>>> since SCSI is broken with this setup. >>>>>>>>>>>> >>>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org> >>>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> When you said "SCSI is broken with this setup", did you mean GP# >>>>>>>>>>> exception when boot up with a hard disk like below? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes that's right. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Do you plan to work on a patch soon? >>>>>>>>> >>>>>>>> >>>>>>>> I tracked down the exception happens at >>>>>>>> part_test_efi()->block_dread() function: >>>>>>>> >>>>>>>> if (!ops->read) >>>>>>>> return -ENOSYS; >>>>>>>> >>>>>>>> Where ops points to nowhere, because underlying SATA device does not >>>>>>>> have a DM driver associated. >>>>>>>> >>>>>>>> Could you please fix this? >>>>>>> >>>>>>> >>>>>>> I've been hoping that someone else will take on this side of things, >>>>>>> but perhaps I am optimistic. I'll see if I can take a look. >>>>>> >>>>>> >>>>>> Thanks. I wanted to fix this myself however I have been busy on some >>>>>> other stuff. >>>>> >>>>> >>>>> I've sent a series which I think puts SCSI and SATA in a better >>>>> position with respect to driver model. However even with that there is >>>>> more work to do. >>>>> >>>> >>>> Thanks for working on this! I will take a look. >>>> >>>> If we don't get enough time to sort out everything, we will have to >>>> revert previous MMC DM conversion patch and leave that to next >>>> release. >>> >>> >>> Yes, let's see how it goes. I probably have time for one more spin if >>> it is soon...but the last patch needs work. >> >> >> As Andreas has pointed out here: >> >> https://lists.denx.de/pipermail/u-boot/2017-June/296337.html >> >> SCSI seems to be broken also on Armada 37xx (and perhaps other >> platforms as well). Is it correct to assume, that this x86 SCSI >> thread is about the same issue? >> >> I know that you are working on DM SCSI support, which is great of >> course. But do you have an idea, if and how this could be fixed for >> this upcoming release? > > Simon already sent a series to convert SCSI to DM and applied to > u-boot-dm. I also sent a series to fix some additional issues [1]. > > Can you or Andreas try on top of u-boot-dm plus my patches to see if > the issue is fixed? > > [1] http://patchwork.ozlabs.org/patch/777312/ I tested with this version and "scsi reset" still reboots the board. Please note that SCSI / AHCI probably needs some additional work, as its currently supported via this driver in arch/arm which needs to moved to the correct driver directory: arch/arm/mach-mvebu/sata.c It probably also needs some work to function correctly with these new DM SCSI patches. But all this seems a bit late in this release cycle. Do we have a "solution" to fix this issue for this upcoming release? Thanks, Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-06-26 7:29 ` Stefan Roese @ 2017-06-26 9:11 ` Bin Meng 2017-06-26 18:42 ` Simon Glass 0 siblings, 1 reply; 22+ messages in thread From: Bin Meng @ 2017-06-26 9:11 UTC (permalink / raw) To: u-boot Hi Stefan, On Mon, Jun 26, 2017 at 3:29 PM, Stefan Roese <sr@denx.de> wrote: > Hi Bin, > > > On 24.06.2017 14:08, Bin Meng wrote: >> >> Hi Stefan, >> >> On Sat, Jun 24, 2017 at 6:29 PM, Stefan Roese <sr@denx.de> wrote: >>> >>> Hi Simon, Hi Bin, >>> >>> >>> On 12.06.2017 05:53, Simon Glass wrote: >>>> >>>> >>>> Hi Bin, >>>> >>>> On 9 June 2017 at 21:47, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>> >>>>> >>>>> Hi Simon, >>>>> >>>>> On Fri, Jun 9, 2017 at 8:27 PM, Simon Glass <sjg@chromium.org> wrote: >>>>>> >>>>>> >>>>>> Hi Bin, >>>>>> >>>>>> On 1 June 2017 at 17:04, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> Hi Simon, >>>>>>> >>>>>>> On Thu, Jun 1, 2017 at 9:14 PM, Simon Glass <sjg@chromium.org> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi Bin, >>>>>>>> >>>>>>>> On 1 June 2017 at 01:27, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Simon, >>>>>>>>> >>>>>>>>> On Wed, May 17, 2017 at 8:42 AM, Bin Meng <bmeng.cn@gmail.com> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Simon, >>>>>>>>>> >>>>>>>>>> On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Bin, >>>>>>>>>>> >>>>>>>>>>> On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Simon, >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This is not to be applied. It is needed to test using >>>>>>>>>>>>> CONFIG_DM_MMC on x86 >>>>>>>>>>>>> since SCSI is broken with this setup. >>>>>>>>>>>>> >>>>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org> >>>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> When you said "SCSI is broken with this setup", did you mean GP# >>>>>>>>>>>> exception when boot up with a hard disk like below? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yes that's right. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Do you plan to work on a patch soon? >>>>>>>>>> >>>>>>>>> >>>>>>>>> I tracked down the exception happens at >>>>>>>>> part_test_efi()->block_dread() function: >>>>>>>>> >>>>>>>>> if (!ops->read) >>>>>>>>> return -ENOSYS; >>>>>>>>> >>>>>>>>> Where ops points to nowhere, because underlying SATA device does >>>>>>>>> not >>>>>>>>> have a DM driver associated. >>>>>>>>> >>>>>>>>> Could you please fix this? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I've been hoping that someone else will take on this side of things, >>>>>>>> but perhaps I am optimistic. I'll see if I can take a look. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks. I wanted to fix this myself however I have been busy on some >>>>>>> other stuff. >>>>>> >>>>>> >>>>>> >>>>>> I've sent a series which I think puts SCSI and SATA in a better >>>>>> position with respect to driver model. However even with that there is >>>>>> more work to do. >>>>>> >>>>> >>>>> Thanks for working on this! I will take a look. >>>>> >>>>> If we don't get enough time to sort out everything, we will have to >>>>> revert previous MMC DM conversion patch and leave that to next >>>>> release. >>>> >>>> >>>> >>>> Yes, let's see how it goes. I probably have time for one more spin if >>>> it is soon...but the last patch needs work. >>> >>> >>> >>> As Andreas has pointed out here: >>> >>> https://lists.denx.de/pipermail/u-boot/2017-June/296337.html >>> >>> SCSI seems to be broken also on Armada 37xx (and perhaps other >>> platforms as well). Is it correct to assume, that this x86 SCSI >>> thread is about the same issue? >>> >>> I know that you are working on DM SCSI support, which is great of >>> course. But do you have an idea, if and how this could be fixed for >>> this upcoming release? >> >> >> Simon already sent a series to convert SCSI to DM and applied to >> u-boot-dm. I also sent a series to fix some additional issues [1]. >> >> Can you or Andreas try on top of u-boot-dm plus my patches to see if >> the issue is fixed? >> >> [1] http://patchwork.ozlabs.org/patch/777312/ > > > I tested with this version and "scsi reset" still reboots the > board. Please note that SCSI / AHCI probably needs some additional > work, as its currently supported via this driver in arch/arm > which needs to moved to the correct driver directory: > > arch/arm/mach-mvebu/sata.c > > It probably also needs some work to function correctly with these > new DM SCSI patches. But all this seems a bit late in this release > cycle. Do we have a "solution" to fix this issue for this upcoming > release? > Did the failure happen at the place part_test_efi()->block_dread() function? if (!ops->read) return -ENOSYS; Where ops points to nowhere .. If so, I think the SATA driver needs to be converted to DM. But I don't know if a simple solution exists for now on your board. I noticed that Andreas said v2017.01 works but v2017.03 is failing. So it has been broken for some time. But Simon's series aims to resolve the issues seen on x86, which is an intermediate issue in this release cycle. Regards, Bin ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-06-26 9:11 ` Bin Meng @ 2017-06-26 18:42 ` Simon Glass 2017-06-26 23:34 ` Bin Meng 2017-06-27 4:48 ` Stefan Roese 0 siblings, 2 replies; 22+ messages in thread From: Simon Glass @ 2017-06-26 18:42 UTC (permalink / raw) To: u-boot Hi, On 26 June 2017 at 03:11, Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Stefan, > > On Mon, Jun 26, 2017 at 3:29 PM, Stefan Roese <sr@denx.de> wrote: > > Hi Bin, > > > > > > On 24.06.2017 14:08, Bin Meng wrote: > >> > >> Hi Stefan, > >> > >> On Sat, Jun 24, 2017 at 6:29 PM, Stefan Roese <sr@denx.de> wrote: > >>> > >>> Hi Simon, Hi Bin, > >>> > >>> > >>> On 12.06.2017 05:53, Simon Glass wrote: > >>>> > >>>> > >>>> Hi Bin, > >>>> > >>>> On 9 June 2017 at 21:47, Bin Meng <bmeng.cn@gmail.com> wrote: > >>>>> > >>>>> > >>>>> Hi Simon, > >>>>> > >>>>> On Fri, Jun 9, 2017 at 8:27 PM, Simon Glass <sjg@chromium.org> wrote: > >>>>>> > >>>>>> > >>>>>> Hi Bin, > >>>>>> > >>>>>> On 1 June 2017 at 17:04, Bin Meng <bmeng.cn@gmail.com> wrote: > >>>>>>> > >>>>>>> > >>>>>>> Hi Simon, > >>>>>>> > >>>>>>> On Thu, Jun 1, 2017 at 9:14 PM, Simon Glass <sjg@chromium.org> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> Hi Bin, > >>>>>>>> > >>>>>>>> On 1 June 2017 at 01:27, Bin Meng <bmeng.cn@gmail.com> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Hi Simon, > >>>>>>>>> > >>>>>>>>> On Wed, May 17, 2017 at 8:42 AM, Bin Meng <bmeng.cn@gmail.com> > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Hi Simon, > >>>>>>>>>> > >>>>>>>>>> On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> > >>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Hi Bin, > >>>>>>>>>>> > >>>>>>>>>>> On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Simon, > >>>>>>>>>>>> > >>>>>>>>>>>> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> This is not to be applied. It is needed to test using > >>>>>>>>>>>>> CONFIG_DM_MMC on x86 > >>>>>>>>>>>>> since SCSI is broken with this setup. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org> > >>>>>>>>>>>>> --- > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> When you said "SCSI is broken with this setup", did you mean GP# > >>>>>>>>>>>> exception when boot up with a hard disk like below? > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Yes that's right. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Do you plan to work on a patch soon? > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> I tracked down the exception happens at > >>>>>>>>> part_test_efi()->block_dread() function: > >>>>>>>>> > >>>>>>>>> if (!ops->read) > >>>>>>>>> return -ENOSYS; > >>>>>>>>> > >>>>>>>>> Where ops points to nowhere, because underlying SATA device does > >>>>>>>>> not > >>>>>>>>> have a DM driver associated. > >>>>>>>>> > >>>>>>>>> Could you please fix this? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I've been hoping that someone else will take on this side of things, > >>>>>>>> but perhaps I am optimistic. I'll see if I can take a look. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Thanks. I wanted to fix this myself however I have been busy on some > >>>>>>> other stuff. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I've sent a series which I think puts SCSI and SATA in a better > >>>>>> position with respect to driver model. However even with that there is > >>>>>> more work to do. > >>>>>> > >>>>> > >>>>> Thanks for working on this! I will take a look. > >>>>> > >>>>> If we don't get enough time to sort out everything, we will have to > >>>>> revert previous MMC DM conversion patch and leave that to next > >>>>> release. > >>>> > >>>> > >>>> > >>>> Yes, let's see how it goes. I probably have time for one more spin if > >>>> it is soon...but the last patch needs work. > >>> > >>> > >>> > >>> As Andreas has pointed out here: > >>> > >>> https://lists.denx.de/pipermail/u-boot/2017-June/296337.html > >>> > >>> SCSI seems to be broken also on Armada 37xx (and perhaps other > >>> platforms as well). Is it correct to assume, that this x86 SCSI > >>> thread is about the same issue? > >>> > >>> I know that you are working on DM SCSI support, which is great of > >>> course. But do you have an idea, if and how this could be fixed for > >>> this upcoming release? > >> > >> > >> Simon already sent a series to convert SCSI to DM and applied to > >> u-boot-dm. I also sent a series to fix some additional issues [1]. > >> > >> Can you or Andreas try on top of u-boot-dm plus my patches to see if > >> the issue is fixed? > >> > >> [1] http://patchwork.ozlabs.org/patch/777312/ > > > > > > I tested with this version and "scsi reset" still reboots the > > board. Please note that SCSI / AHCI probably needs some additional > > work, as its currently supported via this driver in arch/arm > > which needs to moved to the correct driver directory: > > > > arch/arm/mach-mvebu/sata.c > > > > It probably also needs some work to function correctly with these > > new DM SCSI patches. But all this seems a bit late in this release > > cycle. Do we have a "solution" to fix this issue for this upcoming > > release? > > > > Did the failure happen at the place part_test_efi()->block_dread() function? > > if (!ops->read) > return -ENOSYS; > > Where ops points to nowhere .. > > If so, I think the SATA driver needs to be converted to DM. > > But I don't know if a simple solution exists for now on your board. I > noticed that Andreas said v2017.01 works but v2017.03 is failing. So > it has been broken for some time. But Simon's series aims to resolve > the issues seen on x86, which is an intermediate issue in this release > cycle. I sent a pull request (forgetting to cc the list) for this but it was too close to RC2 so Tom rejected it. It is sitting in dm/master if you want to look. At this stage I don't have a good answer. Even my series doesn't complete the SATA conversion to DM. We still need AHCI to have proper operations and convert the rest of the drivers. I was hoping that might be easier once the powerpc removals are complete. Regards, Simon ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-06-26 18:42 ` Simon Glass @ 2017-06-26 23:34 ` Bin Meng 2017-06-27 4:53 ` Stefan Roese 2017-06-27 4:48 ` Stefan Roese 1 sibling, 1 reply; 22+ messages in thread From: Bin Meng @ 2017-06-26 23:34 UTC (permalink / raw) To: u-boot Hi Stefan, On Tue, Jun 27, 2017 at 2:42 AM, Simon Glass <sjg@chromium.org> wrote: > Hi, > > On 26 June 2017 at 03:11, Bin Meng <bmeng.cn@gmail.com> wrote: >> >> Hi Stefan, >> >> On Mon, Jun 26, 2017 at 3:29 PM, Stefan Roese <sr@denx.de> wrote: >> > Hi Bin, >> > >> > >> > On 24.06.2017 14:08, Bin Meng wrote: >> >> >> >> Hi Stefan, >> >> >> >> On Sat, Jun 24, 2017 at 6:29 PM, Stefan Roese <sr@denx.de> wrote: >> >>> >> >>> Hi Simon, Hi Bin, >> >>> >> >>> >> >>> On 12.06.2017 05:53, Simon Glass wrote: >> >>>> >> >>>> >> >>>> Hi Bin, >> >>>> >> >>>> On 9 June 2017 at 21:47, Bin Meng <bmeng.cn@gmail.com> wrote: >> >>>>> >> >>>>> >> >>>>> Hi Simon, >> >>>>> >> >>>>> On Fri, Jun 9, 2017 at 8:27 PM, Simon Glass <sjg@chromium.org> wrote: >> >>>>>> >> >>>>>> >> >>>>>> Hi Bin, >> >>>>>> >> >>>>>> On 1 June 2017 at 17:04, Bin Meng <bmeng.cn@gmail.com> wrote: >> >>>>>>> >> >>>>>>> >> >>>>>>> Hi Simon, >> >>>>>>> >> >>>>>>> On Thu, Jun 1, 2017 at 9:14 PM, Simon Glass <sjg@chromium.org> wrote: >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Hi Bin, >> >>>>>>>> >> >>>>>>>> On 1 June 2017 at 01:27, Bin Meng <bmeng.cn@gmail.com> wrote: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Hi Simon, >> >>>>>>>>> >> >>>>>>>>> On Wed, May 17, 2017 at 8:42 AM, Bin Meng <bmeng.cn@gmail.com> >> >>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> Hi Simon, >> >>>>>>>>>> >> >>>>>>>>>> On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> >> >>>>>>>>>> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> Hi Bin, >> >>>>>>>>>>> >> >>>>>>>>>>> On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Hi Simon, >> >>>>>>>>>>>> >> >>>>>>>>>>>> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> >> >>>>>>>>>>>> wrote: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> This is not to be applied. It is needed to test using >> >>>>>>>>>>>>> CONFIG_DM_MMC on x86 >> >>>>>>>>>>>>> since SCSI is broken with this setup. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org> >> >>>>>>>>>>>>> --- >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> When you said "SCSI is broken with this setup", did you mean GP# >> >>>>>>>>>>>> exception when boot up with a hard disk like below? >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> Yes that's right. >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> Do you plan to work on a patch soon? >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> I tracked down the exception happens at >> >>>>>>>>> part_test_efi()->block_dread() function: >> >>>>>>>>> >> >>>>>>>>> if (!ops->read) >> >>>>>>>>> return -ENOSYS; >> >>>>>>>>> >> >>>>>>>>> Where ops points to nowhere, because underlying SATA device does >> >>>>>>>>> not >> >>>>>>>>> have a DM driver associated. >> >>>>>>>>> >> >>>>>>>>> Could you please fix this? >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> I've been hoping that someone else will take on this side of things, >> >>>>>>>> but perhaps I am optimistic. I'll see if I can take a look. >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> Thanks. I wanted to fix this myself however I have been busy on some >> >>>>>>> other stuff. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> I've sent a series which I think puts SCSI and SATA in a better >> >>>>>> position with respect to driver model. However even with that there is >> >>>>>> more work to do. >> >>>>>> >> >>>>> >> >>>>> Thanks for working on this! I will take a look. >> >>>>> >> >>>>> If we don't get enough time to sort out everything, we will have to >> >>>>> revert previous MMC DM conversion patch and leave that to next >> >>>>> release. >> >>>> >> >>>> >> >>>> >> >>>> Yes, let's see how it goes. I probably have time for one more spin if >> >>>> it is soon...but the last patch needs work. >> >>> >> >>> >> >>> >> >>> As Andreas has pointed out here: >> >>> >> >>> https://lists.denx.de/pipermail/u-boot/2017-June/296337.html >> >>> >> >>> SCSI seems to be broken also on Armada 37xx (and perhaps other >> >>> platforms as well). Is it correct to assume, that this x86 SCSI >> >>> thread is about the same issue? >> >>> >> >>> I know that you are working on DM SCSI support, which is great of >> >>> course. But do you have an idea, if and how this could be fixed for >> >>> this upcoming release? >> >> >> >> >> >> Simon already sent a series to convert SCSI to DM and applied to >> >> u-boot-dm. I also sent a series to fix some additional issues [1]. >> >> >> >> Can you or Andreas try on top of u-boot-dm plus my patches to see if >> >> the issue is fixed? >> >> >> >> [1] http://patchwork.ozlabs.org/patch/777312/ >> > >> > >> > I tested with this version and "scsi reset" still reboots the >> > board. Please note that SCSI / AHCI probably needs some additional >> > work, as its currently supported via this driver in arch/arm >> > which needs to moved to the correct driver directory: >> > >> > arch/arm/mach-mvebu/sata.c >> > >> > It probably also needs some work to function correctly with these >> > new DM SCSI patches. But all this seems a bit late in this release >> > cycle. Do we have a "solution" to fix this issue for this upcoming >> > release? >> > >> >> Did the failure happen at the place part_test_efi()->block_dread() function? >> >> if (!ops->read) >> return -ENOSYS; >> >> Where ops points to nowhere .. >> >> If so, I think the SATA driver needs to be converted to DM. >> >> But I don't know if a simple solution exists for now on your board. I >> noticed that Andreas said v2017.01 works but v2017.03 is failing. So >> it has been broken for some time. But Simon's series aims to resolve >> the issues seen on x86, which is an intermediate issue in this release >> cycle. > > I sent a pull request (forgetting to cc the list) for this but it was > too close to RC2 so Tom rejected it. It is sitting in dm/master if you > want to look. > > At this stage I don't have a good answer. Even my series doesn't > complete the SATA conversion to DM. We still need AHCI to have proper > operations and convert the rest of the drivers. I was hoping that > might be easier once the powerpc removals are complete. Since the pull request of u-boot-dm was rejected for this release, I sent a revert patch for x86 [1] to fix x86 SCSI issues. Is Armada 37xx converted to use DM MMC? If so, maybe a quick fix is to revert the Armada 37xx board back to use non-DM MMC, like x86 does? [1] http://patchwork.ozlabs.org/patch/780913/ Regards, Bin ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-06-26 23:34 ` Bin Meng @ 2017-06-27 4:53 ` Stefan Roese 0 siblings, 0 replies; 22+ messages in thread From: Stefan Roese @ 2017-06-27 4:53 UTC (permalink / raw) To: u-boot Hi Bin, On 27.06.2017 01:34, Bin Meng wrote: > Hi Stefan, > > On Tue, Jun 27, 2017 at 2:42 AM, Simon Glass <sjg@chromium.org> wrote: >> Hi, >> >> On 26 June 2017 at 03:11, Bin Meng <bmeng.cn@gmail.com> wrote: >>> >>> Hi Stefan, >>> >>> On Mon, Jun 26, 2017 at 3:29 PM, Stefan Roese <sr@denx.de> wrote: >>>> Hi Bin, >>>> >>>> >>>> On 24.06.2017 14:08, Bin Meng wrote: >>>>> >>>>> Hi Stefan, >>>>> >>>>> On Sat, Jun 24, 2017 at 6:29 PM, Stefan Roese <sr@denx.de> wrote: >>>>>> >>>>>> Hi Simon, Hi Bin, >>>>>> >>>>>> >>>>>> On 12.06.2017 05:53, Simon Glass wrote: >>>>>>> >>>>>>> >>>>>>> Hi Bin, >>>>>>> >>>>>>> On 9 June 2017 at 21:47, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi Simon, >>>>>>>> >>>>>>>> On Fri, Jun 9, 2017 at 8:27 PM, Simon Glass <sjg@chromium.org> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Bin, >>>>>>>>> >>>>>>>>> On 1 June 2017 at 17:04, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Simon, >>>>>>>>>> >>>>>>>>>> On Thu, Jun 1, 2017 at 9:14 PM, Simon Glass <sjg@chromium.org> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Bin, >>>>>>>>>>> >>>>>>>>>>> On 1 June 2017 at 01:27, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Simon, >>>>>>>>>>>> >>>>>>>>>>>> On Wed, May 17, 2017 at 8:42 AM, Bin Meng <bmeng.cn@gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Simon, >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Bin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Simon, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is not to be applied. It is needed to test using >>>>>>>>>>>>>>>> CONFIG_DM_MMC on x86 >>>>>>>>>>>>>>>> since SCSI is broken with this setup. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org> >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> When you said "SCSI is broken with this setup", did you mean GP# >>>>>>>>>>>>>>> exception when boot up with a hard disk like below? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes that's right. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Do you plan to work on a patch soon? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I tracked down the exception happens at >>>>>>>>>>>> part_test_efi()->block_dread() function: >>>>>>>>>>>> >>>>>>>>>>>> if (!ops->read) >>>>>>>>>>>> return -ENOSYS; >>>>>>>>>>>> >>>>>>>>>>>> Where ops points to nowhere, because underlying SATA device does >>>>>>>>>>>> not >>>>>>>>>>>> have a DM driver associated. >>>>>>>>>>>> >>>>>>>>>>>> Could you please fix this? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've been hoping that someone else will take on this side of things, >>>>>>>>>>> but perhaps I am optimistic. I'll see if I can take a look. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks. I wanted to fix this myself however I have been busy on some >>>>>>>>>> other stuff. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I've sent a series which I think puts SCSI and SATA in a better >>>>>>>>> position with respect to driver model. However even with that there is >>>>>>>>> more work to do. >>>>>>>>> >>>>>>>> >>>>>>>> Thanks for working on this! I will take a look. >>>>>>>> >>>>>>>> If we don't get enough time to sort out everything, we will have to >>>>>>>> revert previous MMC DM conversion patch and leave that to next >>>>>>>> release. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Yes, let's see how it goes. I probably have time for one more spin if >>>>>>> it is soon...but the last patch needs work. >>>>>> >>>>>> >>>>>> >>>>>> As Andreas has pointed out here: >>>>>> >>>>>> https://lists.denx.de/pipermail/u-boot/2017-June/296337.html >>>>>> >>>>>> SCSI seems to be broken also on Armada 37xx (and perhaps other >>>>>> platforms as well). Is it correct to assume, that this x86 SCSI >>>>>> thread is about the same issue? >>>>>> >>>>>> I know that you are working on DM SCSI support, which is great of >>>>>> course. But do you have an idea, if and how this could be fixed for >>>>>> this upcoming release? >>>>> >>>>> >>>>> Simon already sent a series to convert SCSI to DM and applied to >>>>> u-boot-dm. I also sent a series to fix some additional issues [1]. >>>>> >>>>> Can you or Andreas try on top of u-boot-dm plus my patches to see if >>>>> the issue is fixed? >>>>> >>>>> [1] http://patchwork.ozlabs.org/patch/777312/ >>>> >>>> >>>> I tested with this version and "scsi reset" still reboots the >>>> board. Please note that SCSI / AHCI probably needs some additional >>>> work, as its currently supported via this driver in arch/arm >>>> which needs to moved to the correct driver directory: >>>> >>>> arch/arm/mach-mvebu/sata.c >>>> >>>> It probably also needs some work to function correctly with these >>>> new DM SCSI patches. But all this seems a bit late in this release >>>> cycle. Do we have a "solution" to fix this issue for this upcoming >>>> release? >>>> >>> >>> Did the failure happen at the place part_test_efi()->block_dread() function? >>> >>> if (!ops->read) >>> return -ENOSYS; >>> >>> Where ops points to nowhere .. >>> >>> If so, I think the SATA driver needs to be converted to DM. >>> >>> But I don't know if a simple solution exists for now on your board. I >>> noticed that Andreas said v2017.01 works but v2017.03 is failing. So >>> it has been broken for some time. But Simon's series aims to resolve >>> the issues seen on x86, which is an intermediate issue in this release >>> cycle. >> >> I sent a pull request (forgetting to cc the list) for this but it was >> too close to RC2 so Tom rejected it. It is sitting in dm/master if you >> want to look. >> >> At this stage I don't have a good answer. Even my series doesn't >> complete the SATA conversion to DM. We still need AHCI to have proper >> operations and convert the rest of the drivers. I was hoping that >> might be easier once the powerpc removals are complete. > > Since the pull request of u-boot-dm was rejected for this release, I > sent a revert patch for x86 [1] to fix x86 SCSI issues. > > Is Armada 37xx converted to use DM MMC? If so, maybe a quick fix is to > revert the Armada 37xx board back to use non-DM MMC, like x86 does? The SDHCI driver for Armada 37xx (and 7k/8k) was added only recently and directly as a DM driver. So I can't move it back to non-DM without bigger effort - which does not make much sense. My feeling is, that its probably best to do the SCSI / AHCI DM conversion soon in the next release cycle and I will definitely help with converting / testing on the Armada 64bit platforms then. Thanks, Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 2017-06-26 18:42 ` Simon Glass 2017-06-26 23:34 ` Bin Meng @ 2017-06-27 4:48 ` Stefan Roese 1 sibling, 0 replies; 22+ messages in thread From: Stefan Roese @ 2017-06-27 4:48 UTC (permalink / raw) To: u-boot Hi Simon, On 26.06.2017 20:42, Simon Glass wrote: > Hi, > > On 26 June 2017 at 03:11, Bin Meng <bmeng.cn@gmail.com> wrote: >> >> Hi Stefan, >> >> On Mon, Jun 26, 2017 at 3:29 PM, Stefan Roese <sr@denx.de> wrote: >>> Hi Bin, >>> >>> >>> On 24.06.2017 14:08, Bin Meng wrote: >>>> >>>> Hi Stefan, >>>> >>>> On Sat, Jun 24, 2017 at 6:29 PM, Stefan Roese <sr@denx.de> wrote: >>>>> >>>>> Hi Simon, Hi Bin, >>>>> >>>>> >>>>> On 12.06.2017 05:53, Simon Glass wrote: >>>>>> >>>>>> >>>>>> Hi Bin, >>>>>> >>>>>> On 9 June 2017 at 21:47, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> Hi Simon, >>>>>>> >>>>>>> On Fri, Jun 9, 2017 at 8:27 PM, Simon Glass <sjg@chromium.org> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi Bin, >>>>>>>> >>>>>>>> On 1 June 2017 at 17:04, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Simon, >>>>>>>>> >>>>>>>>> On Thu, Jun 1, 2017 at 9:14 PM, Simon Glass <sjg@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Bin, >>>>>>>>>> >>>>>>>>>> On 1 June 2017 at 01:27, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Simon, >>>>>>>>>>> >>>>>>>>>>> On Wed, May 17, 2017 at 8:42 AM, Bin Meng <bmeng.cn@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Simon, >>>>>>>>>>>> >>>>>>>>>>>> On Sat, May 13, 2017 at 9:11 AM, Simon Glass <sjg@chromium.org> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Bin, >>>>>>>>>>>>> >>>>>>>>>>>>> On 8 May 2017 at 01:05, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Simon, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is not to be applied. It is needed to test using >>>>>>>>>>>>>>> CONFIG_DM_MMC on x86 >>>>>>>>>>>>>>> since SCSI is broken with this setup. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org> >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> When you said "SCSI is broken with this setup", did you mean GP# >>>>>>>>>>>>>> exception when boot up with a hard disk like below? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yes that's right. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Do you plan to work on a patch soon? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I tracked down the exception happens at >>>>>>>>>>> part_test_efi()->block_dread() function: >>>>>>>>>>> >>>>>>>>>>> if (!ops->read) >>>>>>>>>>> return -ENOSYS; >>>>>>>>>>> >>>>>>>>>>> Where ops points to nowhere, because underlying SATA device does >>>>>>>>>>> not >>>>>>>>>>> have a DM driver associated. >>>>>>>>>>> >>>>>>>>>>> Could you please fix this? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've been hoping that someone else will take on this side of things, >>>>>>>>>> but perhaps I am optimistic. I'll see if I can take a look. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks. I wanted to fix this myself however I have been busy on some >>>>>>>>> other stuff. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I've sent a series which I think puts SCSI and SATA in a better >>>>>>>> position with respect to driver model. However even with that there is >>>>>>>> more work to do. >>>>>>>> >>>>>>> >>>>>>> Thanks for working on this! I will take a look. >>>>>>> >>>>>>> If we don't get enough time to sort out everything, we will have to >>>>>>> revert previous MMC DM conversion patch and leave that to next >>>>>>> release. >>>>>> >>>>>> >>>>>> >>>>>> Yes, let's see how it goes. I probably have time for one more spin if >>>>>> it is soon...but the last patch needs work. >>>>> >>>>> >>>>> >>>>> As Andreas has pointed out here: >>>>> >>>>> https://lists.denx.de/pipermail/u-boot/2017-June/296337.html >>>>> >>>>> SCSI seems to be broken also on Armada 37xx (and perhaps other >>>>> platforms as well). Is it correct to assume, that this x86 SCSI >>>>> thread is about the same issue? >>>>> >>>>> I know that you are working on DM SCSI support, which is great of >>>>> course. But do you have an idea, if and how this could be fixed for >>>>> this upcoming release? >>>> >>>> >>>> Simon already sent a series to convert SCSI to DM and applied to >>>> u-boot-dm. I also sent a series to fix some additional issues [1]. >>>> >>>> Can you or Andreas try on top of u-boot-dm plus my patches to see if >>>> the issue is fixed? >>>> >>>> [1] http://patchwork.ozlabs.org/patch/777312/ >>> >>> >>> I tested with this version and "scsi reset" still reboots the >>> board. Please note that SCSI / AHCI probably needs some additional >>> work, as its currently supported via this driver in arch/arm >>> which needs to moved to the correct driver directory: >>> >>> arch/arm/mach-mvebu/sata.c >>> >>> It probably also needs some work to function correctly with these >>> new DM SCSI patches. But all this seems a bit late in this release >>> cycle. Do we have a "solution" to fix this issue for this upcoming >>> release? >>> >> >> Did the failure happen at the place part_test_efi()->block_dread() function? >> >> if (!ops->read) >> return -ENOSYS; >> >> Where ops points to nowhere .. >> >> If so, I think the SATA driver needs to be converted to DM. >> >> But I don't know if a simple solution exists for now on your board. I >> noticed that Andreas said v2017.01 works but v2017.03 is failing. So >> it has been broken for some time. But Simon's series aims to resolve >> the issues seen on x86, which is an intermediate issue in this release >> cycle. > > I sent a pull request (forgetting to cc the list) for this but it was > too close to RC2 so Tom rejected it. It is sitting in dm/master if you > want to look. Thanks for the explanation. > At this stage I don't have a good answer. Even my series doesn't > complete the SATA conversion to DM. We still need AHCI to have proper > operations and convert the rest of the drivers. I was hoping that > might be easier once the powerpc removals are complete. Understood. Might be that we can only solve this in the next release cycle then. Thanks, Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 2/2] x86: Convert MMC to driver model 2017-04-10 0:38 [U-Boot] [PATCH 0/2] x86: Convert all boards to use MMC to driver model Simon Glass 2017-04-10 0:38 ` [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 Simon Glass @ 2017-04-10 0:38 ` Simon Glass 2017-05-08 3:10 ` Bin Meng 1 sibling, 1 reply; 22+ messages in thread From: Simon Glass @ 2017-04-10 0:38 UTC (permalink / raw) To: u-boot Convert the pci_mmc driver over to driver model and migrate all x86 boards that use it. Signed-off-by: Simon Glass <sjg@chromium.org> --- arch/Kconfig | 1 + arch/x86/cpu/baytrail/valleyview.c | 12 ------ arch/x86/cpu/quark/quark.c | 10 ----- arch/x86/cpu/queensbay/Makefile | 2 +- arch/x86/cpu/queensbay/topcliff.c | 20 --------- drivers/mmc/pci_mmc.c | 86 ++++++++++++++++++++++++++------------ include/mmc.h | 12 ------ 7 files changed, 62 insertions(+), 81 deletions(-) delete mode 100644 arch/x86/cpu/queensbay/topcliff.c diff --git a/arch/Kconfig b/arch/Kconfig index 160accdbcb..97aa7d9fc1 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -84,6 +84,7 @@ config X86 select DM_GPIO select DM_SPI select DM_SPI_FLASH + select DM_MMC if MMC config XTENSA bool "Xtensa architecture" diff --git a/arch/x86/cpu/baytrail/valleyview.c b/arch/x86/cpu/baytrail/valleyview.c index 87ba849c1c..c58f6a86a8 100644 --- a/arch/x86/cpu/baytrail/valleyview.c +++ b/arch/x86/cpu/baytrail/valleyview.c @@ -11,18 +11,6 @@ #include <asm/mrccache.h> #include <asm/post.h> -static struct pci_device_id mmc_supported[] = { - { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT_SDIO }, - { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT_SD }, - { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT_EMMC2 }, - {}, -}; - -int cpu_mmc_init(bd_t *bis) -{ - return pci_mmc_init("ValleyView SDHCI", mmc_supported); -} - #ifndef CONFIG_EFI_APP int arch_cpu_init(void) { diff --git a/arch/x86/cpu/quark/quark.c b/arch/x86/cpu/quark/quark.c index 0c2cea4ee9..c36a5892d5 100644 --- a/arch/x86/cpu/quark/quark.c +++ b/arch/x86/cpu/quark/quark.c @@ -16,11 +16,6 @@ #include <asm/arch/msg_port.h> #include <asm/arch/quark.h> -static struct pci_device_id mmc_supported[] = { - { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_QRK_SDIO }, - {}, -}; - static void quark_setup_mtrr(void) { u32 base, mask; @@ -328,11 +323,6 @@ int arch_early_init_r(void) return 0; } -int cpu_mmc_init(bd_t *bis) -{ - return pci_mmc_init("Quark SDHCI", mmc_supported); -} - int arch_misc_init(void) { #ifdef CONFIG_ENABLE_MRC_CACHE diff --git a/arch/x86/cpu/queensbay/Makefile b/arch/x86/cpu/queensbay/Makefile index af3ffad385..c0681995bd 100644 --- a/arch/x86/cpu/queensbay/Makefile +++ b/arch/x86/cpu/queensbay/Makefile @@ -5,4 +5,4 @@ # obj-y += fsp_configs.o irq.o -obj-y += tnc.o topcliff.o +obj-y += tnc.o diff --git a/arch/x86/cpu/queensbay/topcliff.c b/arch/x86/cpu/queensbay/topcliff.c deleted file mode 100644 index b76dd7de69..0000000000 --- a/arch/x86/cpu/queensbay/topcliff.c +++ /dev/null @@ -1,20 +0,0 @@ -/* - * Copyright (C) 2014, Bin Meng <bmeng.cn@gmail.com> - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -#include <common.h> -#include <mmc.h> -#include <pci_ids.h> - -static struct pci_device_id mmc_supported[] = { - { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SDIO_0 }, - { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SDIO_1 }, - {}, -}; - -int cpu_mmc_init(bd_t *bis) -{ - return pci_mmc_init("Topcliff SDHCI", mmc_supported); -} diff --git a/drivers/mmc/pci_mmc.c b/drivers/mmc/pci_mmc.c index e39b476834..6db89779ba 100644 --- a/drivers/mmc/pci_mmc.c +++ b/drivers/mmc/pci_mmc.c @@ -6,37 +6,71 @@ */ #include <common.h> +#include <dm.h> #include <errno.h> #include <malloc.h> +#include <mapmem.h> #include <sdhci.h> #include <asm/pci.h> -int pci_mmc_init(const char *name, struct pci_device_id *mmc_supported) +struct pci_mmc_plat { + struct mmc_config cfg; + struct mmc mmc; +}; + +struct pci_mmc_priv { + struct sdhci_host host; + void *base; +}; + +static int pci_mmc_probe(struct udevice *dev) { - struct sdhci_host *mmc_host; - u32 iobase; + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev); + struct pci_mmc_plat *plat = dev_get_platdata(dev); + struct pci_mmc_priv *priv = dev_get_priv(dev); + struct sdhci_host *host = &priv->host; + u32 ioaddr; int ret; - int i; - - for (i = 0; ; i++) { - struct udevice *dev; - - ret = pci_find_device_id(mmc_supported, i, &dev); - if (ret) - return ret; - mmc_host = malloc(sizeof(struct sdhci_host)); - if (!mmc_host) - return -ENOMEM; - - mmc_host->name = name; - dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0, &iobase); - mmc_host->ioaddr = (void *)(ulong)iobase; - mmc_host->quirks = 0; - mmc_host->max_clk = 0; - ret = add_sdhci(mmc_host, 0, 0); - if (ret) - return ret; - } - - return 0; + + dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0, &ioaddr); + host->ioaddr = map_sysmem(ioaddr, 0); + host->name = dev->name; + ret = sdhci_setup_cfg(&plat->cfg, host, 0, 0); + if (ret) + return ret; + host->mmc = &plat->mmc; + host->mmc->priv = &priv->host; + host->mmc->dev = dev; + upriv->mmc = host->mmc; + + return sdhci_probe(dev); } + +static int pci_mmc_bind(struct udevice *dev) +{ + struct pci_mmc_plat *plat = dev_get_platdata(dev); + + return sdhci_bind(dev, &plat->mmc, &plat->cfg); +} + +U_BOOT_DRIVER(pci_mmc) = { + .name = "pci_mmc", + .id = UCLASS_MMC, + .bind = pci_mmc_bind, + .probe = pci_mmc_probe, + .ops = &sdhci_ops, + .priv_auto_alloc_size = sizeof(struct pci_mmc_priv), + .platdata_auto_alloc_size = sizeof(struct pci_mmc_plat), +}; + +static struct pci_device_id mmc_supported[] = { + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT_SDIO) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT_SD) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT_EMMC2) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_QRK_SDIO) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SDIO_0) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SDIO_1) }, + {}, +}; + +U_BOOT_PCI_DEVICE(pci_mmc, mmc_supported); diff --git a/include/mmc.h b/include/mmc.h index fad12d608c..8346b0e19e 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -585,18 +585,6 @@ int cpu_mmc_init(bd_t *bis); int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr); int mmc_get_env_dev(void); -struct pci_device_id; - -/** - * pci_mmc_init() - set up PCI MMC devices - * - * This finds all the matching PCI IDs and sets them up as MMC devices. - * - * @name: Name to use for devices - * @mmc_supported: PCI IDs to search for, terminated by {0, 0} - */ -int pci_mmc_init(const char *name, struct pci_device_id *mmc_supported); - /* Set block count limit because of 16 bit register limit on some hardware*/ #ifndef CONFIG_SYS_MMC_MAX_BLK_COUNT #define CONFIG_SYS_MMC_MAX_BLK_COUNT 65535 -- 2.12.2.715.g7642488e1d-goog ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 2/2] x86: Convert MMC to driver model 2017-04-10 0:38 ` [U-Boot] [PATCH 2/2] x86: Convert MMC to driver model Simon Glass @ 2017-05-08 3:10 ` Bin Meng 2017-05-08 3:13 ` Bin Meng 0 siblings, 1 reply; 22+ messages in thread From: Bin Meng @ 2017-05-08 3:10 UTC (permalink / raw) To: u-boot On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> wrote: > Convert the pci_mmc driver over to driver model and migrate all x86 boards > that use it. > > Signed-off-by: Simon Glass <sjg@chromium.org> > --- > > arch/Kconfig | 1 + > arch/x86/cpu/baytrail/valleyview.c | 12 ------ > arch/x86/cpu/quark/quark.c | 10 ----- > arch/x86/cpu/queensbay/Makefile | 2 +- > arch/x86/cpu/queensbay/topcliff.c | 20 --------- > drivers/mmc/pci_mmc.c | 86 ++++++++++++++++++++++++++------------ > include/mmc.h | 12 ------ > 7 files changed, 62 insertions(+), 81 deletions(-) > delete mode 100644 arch/x86/cpu/queensbay/topcliff.c > Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested on MinnowMax Tested-by: Bin Meng <bmeng.cn@gmail.com> ^ permalink raw reply [flat|nested] 22+ messages in thread
* [U-Boot] [PATCH 2/2] x86: Convert MMC to driver model 2017-05-08 3:10 ` Bin Meng @ 2017-05-08 3:13 ` Bin Meng 0 siblings, 0 replies; 22+ messages in thread From: Bin Meng @ 2017-05-08 3:13 UTC (permalink / raw) To: u-boot On Mon, May 8, 2017 at 11:10 AM, Bin Meng <bmeng.cn@gmail.com> wrote: > On Mon, Apr 10, 2017 at 8:38 AM, Simon Glass <sjg@chromium.org> wrote: >> Convert the pci_mmc driver over to driver model and migrate all x86 boards >> that use it. >> >> Signed-off-by: Simon Glass <sjg@chromium.org> >> --- >> >> arch/Kconfig | 1 + >> arch/x86/cpu/baytrail/valleyview.c | 12 ------ >> arch/x86/cpu/quark/quark.c | 10 ----- >> arch/x86/cpu/queensbay/Makefile | 2 +- >> arch/x86/cpu/queensbay/topcliff.c | 20 --------- >> drivers/mmc/pci_mmc.c | 86 ++++++++++++++++++++++++++------------ >> include/mmc.h | 12 ------ >> 7 files changed, 62 insertions(+), 81 deletions(-) >> delete mode 100644 arch/x86/cpu/queensbay/topcliff.c >> > > Reviewed-by: Bin Meng <bmeng.cn@gmail.com> > > Tested on MinnowMax > Tested-by: Bin Meng <bmeng.cn@gmail.com> applied to u-boot-x86/next, thanks! ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2017-06-27 4:53 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-10 0:38 [U-Boot] [PATCH 0/2] x86: Convert all boards to use MMC to driver model Simon Glass 2017-04-10 0:38 ` [U-Boot] [PATCH 1/2] WIP: Disable SCSI on x86 Simon Glass 2017-05-08 7:05 ` Bin Meng 2017-05-13 1:11 ` Simon Glass 2017-05-17 0:42 ` Bin Meng 2017-06-01 7:27 ` Bin Meng 2017-06-01 13:14 ` Simon Glass 2017-06-01 23:04 ` Bin Meng 2017-06-09 12:27 ` Simon Glass 2017-06-10 3:47 ` Bin Meng 2017-06-12 3:53 ` Simon Glass 2017-06-24 10:29 ` Stefan Roese 2017-06-24 12:08 ` Bin Meng 2017-06-26 7:29 ` Stefan Roese 2017-06-26 9:11 ` Bin Meng 2017-06-26 18:42 ` Simon Glass 2017-06-26 23:34 ` Bin Meng 2017-06-27 4:53 ` Stefan Roese 2017-06-27 4:48 ` Stefan Roese 2017-04-10 0:38 ` [U-Boot] [PATCH 2/2] x86: Convert MMC to driver model Simon Glass 2017-05-08 3:10 ` Bin Meng 2017-05-08 3:13 ` Bin Meng
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.