[U-Boot] Testing u-boot-dm/next
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
Hi Simon,
On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass sjg@chromium.org wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
I've tested it on CrownBay board and found one issue:
During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
Invalid bus 0 (err=-19)
I have not investigated but suspect this is due to the CrownBay board has not been converted to use DM SPI, like Chromebook?
Regards, Bin
Hi Bin,
On 9 April 2015 at 06:52, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass sjg@chromium.org wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
I've tested it on CrownBay board and found one issue:
During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
Invalid bus 0 (err=-19)
I have not investigated but suspect this is due to the CrownBay board has not been converted to use DM SPI, like Chromebook?
All of x86 should use that - it is in arch/x86/Kconfig.
More likely the SPI compatible string is wrong:
compatible = "intel,ich7";
It should be "intel,ich-spi "I think. You can check with 'dm tree' to see what devices have been found.
Regards, Simon
Hi Simon,
On Sat, Apr 11, 2015 at 1:42 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 9 April 2015 at 06:52, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass sjg@chromium.org wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
I've tested it on CrownBay board and found one issue:
During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
Invalid bus 0 (err=-19)
I have not investigated but suspect this is due to the CrownBay board has not been converted to use DM SPI, like Chromebook?
All of x86 should use that - it is in arch/x86/Kconfig.
Ah, I see.
More likely the SPI compatible string is wrong:
compatible = "intel,ich7";
It should be "intel,ich-spi "I think. You can check with 'dm tree' to see what devices have been found.
But changing crownbay.dts to use "intel,ich-spi" does not help.
=> dm tree Class Probed Name ---------------------------------------- root [ + ] root_driver serial [ + ] |-- serial gpio [ ] |-- gpioa gpio [ ] |-- gpiob spi [ ] `-- spi spi_flash [ ] `-- spi-flash@0 => sf probe Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19)
Regards, Bin
Hi Simon,
On Sat, Apr 11, 2015 at 9:22 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sat, Apr 11, 2015 at 1:42 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 9 April 2015 at 06:52, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass sjg@chromium.org wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
I've tested it on CrownBay board and found one issue:
During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
Invalid bus 0 (err=-19)
I have not investigated but suspect this is due to the CrownBay board has not been converted to use DM SPI, like Chromebook?
All of x86 should use that - it is in arch/x86/Kconfig.
Ah, I see.
More likely the SPI compatible string is wrong:
compatible = "intel,ich7";
It should be "intel,ich-spi "I think. You can check with 'dm tree' to see what devices have been found.
But changing crownbay.dts to use "intel,ich-spi" does not help.
=> dm tree Class Probed Name
root [ + ] root_driver serial [ + ] |-- serial gpio [ ] |-- gpioa gpio [ ] |-- gpiob spi [ ] `-- spi spi_flash [ ] `-- spi-flash@0 => sf probe Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19)
'git besect' shows that commit 898ed91 breaks the things.
A debug version of U-Boot log is:
=> sf probe uclass_find_device_by_seq: 0 0 - -1 -1 - not found spi_find_bus_and_cs: No bus 0 uclass_find_device_by_seq: 0 0 - -1 -1 - not found uclass_find_device_by_seq: 1 0 - -1 -1 - not found Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19) Command failed, result=1=>
Regards, Bin
Hi Bin,
On 11 April 2015 at 07:48, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sat, Apr 11, 2015 at 9:22 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sat, Apr 11, 2015 at 1:42 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 9 April 2015 at 06:52, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass sjg@chromium.org wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
I've tested it on CrownBay board and found one issue:
During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
Invalid bus 0 (err=-19)
I have not investigated but suspect this is due to the CrownBay board has not been converted to use DM SPI, like Chromebook?
All of x86 should use that - it is in arch/x86/Kconfig.
Ah, I see.
More likely the SPI compatible string is wrong:
compatible = "intel,ich7";
It should be "intel,ich-spi "I think. You can check with 'dm tree' to see what devices have been found.
But changing crownbay.dts to use "intel,ich-spi" does not help.
=> dm tree Class Probed Name
root [ + ] root_driver serial [ + ] |-- serial gpio [ ] |-- gpioa gpio [ ] |-- gpiob spi [ ] `-- spi spi_flash [ ] `-- spi-flash@0 => sf probe Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19)
'git besect' shows that commit 898ed91 breaks the things.
A debug version of U-Boot log is:
=> sf probe uclass_find_device_by_seq: 0 0
- -1 -1
- not found
spi_find_bus_and_cs: No bus 0 uclass_find_device_by_seq: 0 0
- -1 -1
- not found
uclass_find_device_by_seq: 1 0
- -1 -1
- not found
Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19) Command failed, result=1=>
OK thanks, let me take a look...
Regards, Simon
Hi Bin,
On 11 April 2015 at 07:48, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sat, Apr 11, 2015 at 9:22 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sat, Apr 11, 2015 at 1:42 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 9 April 2015 at 06:52, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass sjg@chromium.org wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
I've tested it on CrownBay board and found one issue:
During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
Invalid bus 0 (err=-19)
I have not investigated but suspect this is due to the CrownBay board has not been converted to use DM SPI, like Chromebook?
All of x86 should use that - it is in arch/x86/Kconfig.
Ah, I see.
More likely the SPI compatible string is wrong:
compatible = "intel,ich7";
It should be "intel,ich-spi "I think. You can check with 'dm tree' to see what devices have been found.
But changing crownbay.dts to use "intel,ich-spi" does not help.
=> dm tree Class Probed Name
root [ + ] root_driver serial [ + ] |-- serial gpio [ ] |-- gpioa gpio [ ] |-- gpiob spi [ ] `-- spi spi_flash [ ] `-- spi-flash@0 => sf probe Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19)
'git besect' shows that commit 898ed91 breaks the things.
A debug version of U-Boot log is:
=> sf probe uclass_find_device_by_seq: 0 0
- -1 -1
- not found
spi_find_bus_and_cs: No bus 0 uclass_find_device_by_seq: 0 0
- -1 -1
- not found
uclass_find_device_by_seq: 1 0
- -1 -1
- not found
Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19) Command failed, result=1=>
With the conversion to driver model it no-longer probes the PCI bus looking for a SPI device. Did you try adding and alias too? I think you fixed the compatible string.
I have tested this again on link and it seems OK there (there is an unrelated problem with coreboot not supporting the pch and so not seeing SPI which I will look at).
Since you have a SPI bus device, and its sequence number appears to be unset, it should just be a case of sorting that out.
Can you send the output of 'dm uclass'.
Regards, Simon
Hi Simon,
On Mon, Apr 13, 2015 at 10:27 PM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 11 April 2015 at 07:48, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sat, Apr 11, 2015 at 9:22 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sat, Apr 11, 2015 at 1:42 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 9 April 2015 at 06:52, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass sjg@chromium.org wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
> Hi, > > I have quite a few patches queued up in the next branch of u-boot-dm, > ready for when the merge window options. > > If anyone has time and can give it a spin on their board, it would be much > appreciated! > > Regards, > Simon >
I've tested it on CrownBay board and found one issue:
During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
Invalid bus 0 (err=-19)
I have not investigated but suspect this is due to the CrownBay board has not been converted to use DM SPI, like Chromebook?
All of x86 should use that - it is in arch/x86/Kconfig.
Ah, I see.
More likely the SPI compatible string is wrong:
compatible = "intel,ich7";
It should be "intel,ich-spi "I think. You can check with 'dm tree' to see what devices have been found.
But changing crownbay.dts to use "intel,ich-spi" does not help.
=> dm tree Class Probed Name
root [ + ] root_driver serial [ + ] |-- serial gpio [ ] |-- gpioa gpio [ ] |-- gpiob spi [ ] `-- spi spi_flash [ ] `-- spi-flash@0 => sf probe Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19)
'git besect' shows that commit 898ed91 breaks the things.
A debug version of U-Boot log is:
=> sf probe uclass_find_device_by_seq: 0 0
- -1 -1
- not found
spi_find_bus_and_cs: No bus 0 uclass_find_device_by_seq: 0 0
- -1 -1
- not found
uclass_find_device_by_seq: 1 0
- -1 -1
- not found
Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19) Command failed, result=1=>
With the conversion to driver model it no-longer probes the PCI bus looking for a SPI device. Did you try adding and alias too? I think you fixed the compatible string.
Yes, I only fixed the compatible string. Just now I added an alias to the spi node, and it worked. So the alias is a must-have now?
diff --git a/arch/x86/dts/crownbay.dts b/arch/x86/dts/crownbay.dts index e81054e..fbdeade 100644 --- a/arch/x86/dts/crownbay.dts +++ b/arch/x86/dts/crownbay.dts @@ -13,6 +13,10 @@ model = "Intel Crown Bay"; compatible = "intel,crownbay", "intel,queensbay";
+ aliases { + spi0 = "/spi"; /* looks like spi = "/spi" also works */ + }; + config { silent_console = <0>; }; @@ -46,7 +50,7 @@ spi { #address-cells = <1>; #size-cells = <0>; - compatible = "intel,ich7"; + compatible = "intel,ich-spi"; spi-flash@0 { reg = <0>; compatible = "sst,25vf016b", "spi-flash";
I have tested this again on link and it seems OK there (there is an unrelated problem with coreboot not supporting the pch and so not seeing SPI which I will look at).
Since you have a SPI bus device, and its sequence number appears to be unset, it should just be a case of sorting that out.
Can you send the output of 'dm uclass'.
We need fix crownbay/minnowmax/galileo dts files. I can prepare patches if you like.
Regards, Bin
Hi Bin,
On 13 April 2015 at 09:05, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Apr 13, 2015 at 10:27 PM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 11 April 2015 at 07:48, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sat, Apr 11, 2015 at 9:22 PM, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sat, Apr 11, 2015 at 1:42 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 9 April 2015 at 06:52, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass sjg@chromium.org wrote: > (Correcting address for Masahiro, sorry) > > > On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote: > >> Hi, >> >> I have quite a few patches queued up in the next branch of u-boot-dm, >> ready for when the merge window options. >> >> If anyone has time and can give it a spin on their board, it would be much >> appreciated! >> >> Regards, >> Simon >>
I've tested it on CrownBay board and found one issue:
During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
Invalid bus 0 (err=-19)
I have not investigated but suspect this is due to the CrownBay board has not been converted to use DM SPI, like Chromebook?
All of x86 should use that - it is in arch/x86/Kconfig.
Ah, I see.
More likely the SPI compatible string is wrong:
compatible = "intel,ich7";
It should be "intel,ich-spi "I think. You can check with 'dm tree' to see what devices have been found.
But changing crownbay.dts to use "intel,ich-spi" does not help.
=> dm tree Class Probed Name
root [ + ] root_driver serial [ + ] |-- serial gpio [ ] |-- gpioa gpio [ ] |-- gpiob spi [ ] `-- spi spi_flash [ ] `-- spi-flash@0 => sf probe Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19)
'git besect' shows that commit 898ed91 breaks the things.
A debug version of U-Boot log is:
=> sf probe uclass_find_device_by_seq: 0 0
- -1 -1
- not found
spi_find_bus_and_cs: No bus 0 uclass_find_device_by_seq: 0 0
- -1 -1
- not found
uclass_find_device_by_seq: 1 0
- -1 -1
- not found
Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19) Command failed, result=1=>
With the conversion to driver model it no-longer probes the PCI bus looking for a SPI device. Did you try adding and alias too? I think you fixed the compatible string.
Yes, I only fixed the compatible string. Just now I added an alias to the spi node, and it worked. So the alias is a must-have now?
U-Boot relies on being able to number its devices (at least until we decide we want to allow device names in commands like 'sf probe'). If a device has no sequence number it will be allocated when the device is probed. But until it is probed we can't know what the sequence number will be - it depends on the order that devices are probed. So it is best to explicitly give devices a number I think.
It is certainly possible to change this - e.g. by figuring out the next available sequence number, knowing that this is what the to-be-probed device will be allocated. But we don't do that at present.
diff --git a/arch/x86/dts/crownbay.dts b/arch/x86/dts/crownbay.dts index e81054e..fbdeade 100644 --- a/arch/x86/dts/crownbay.dts +++ b/arch/x86/dts/crownbay.dts @@ -13,6 +13,10 @@ model = "Intel Crown Bay"; compatible = "intel,crownbay", "intel,queensbay";
aliases {spi0 = "/spi"; /* looks like spi = "/spi" also works */};config { silent_console = <0>; };@@ -46,7 +50,7 @@ spi { #address-cells = <1>; #size-cells = <0>;
compatible = "intel,ich7";
compatible = "intel,ich-spi"; spi-flash@0 { reg = <0>; compatible = "sst,25vf016b", "spi-flash";I have tested this again on link and it seems OK there (there is an unrelated problem with coreboot not supporting the pch and so not seeing SPI which I will look at).
Since you have a SPI bus device, and its sequence number appears to be unset, it should just be a case of sorting that out.
Can you send the output of 'dm uclass'.
We need fix crownbay/minnowmax/galileo dts files. I can prepare patches if you like.
Yes please. Sorry I missed this implication of the change.
Regards, Simon
Hi Bin,
On 11 April 2015 at 07:22, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sat, Apr 11, 2015 at 1:42 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 9 April 2015 at 06:52, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Apr 9, 2015 at 11:11 AM, Simon Glass sjg@chromium.org wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
I've tested it on CrownBay board and found one issue:
During the boot up, or typing 'sf probe' in the U-Boot shell, it reports:
Invalid bus 0 (err=-19)
I have not investigated but suspect this is due to the CrownBay board has not been converted to use DM SPI, like Chromebook?
All of x86 should use that - it is in arch/x86/Kconfig.
Ah, I see.
More likely the SPI compatible string is wrong:
compatible = "intel,ich7";
It should be "intel,ich-spi "I think. You can check with 'dm tree' to see what devices have been found.
But changing crownbay.dts to use "intel,ich-spi" does not help.
=> dm tree Class Probed Name
root [ + ] root_driver serial [ + ] |-- serial gpio [ ] |-- gpioa gpio [ ] |-- gpiob spi [ ] `-- spi spi_flash [ ] `-- spi-flash@0 => sf probe Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19)
'dm uclass' will show the bus number. I suspect you need to add an alias for spi0, as with chromebook_link.dts.
Regards, Simon
On 04/08/2015 09:11 PM, Simon Glass wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
On Jetson TK1, there's something up with USB. Here's a good run with something based on a merge of v2015.0r-rc5 and a merge of u-boot-tegra/master from around the end of March:
Tegra124 (Jetson TK1) # usb start starting USB... USB0: USB EHCI 1.10 scanning bus 0 for devices... 1 USB Device(s) found USB1: USB EHCI 1.10 scanning bus 1 for devices... 6 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found Tegra124 (Jetson TK1) # usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller
2 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-3 Hub (480 Mb/s, 100mA) | USB2.0 Hub | +-4 Hub (480 Mb/s, 100mA) | | USB2.0 Hub | | | +-5 Human Interface (1.5 Mb/s, 100mA) | | Microsoft Microsoft IntelliMouse� Explore | | | +-6 Human Interface (1.5 Mb/s, 70mA) | LITEON Technology USB Multimedia Keyboard | +-7 Mass Storage (480 Mb/s, 2mA) Sunplus Innovation Technology. USB to Serial-ATA bridge FF980813AF0000000000005FF16BFF
... and here's u-boot-dm/next
Tegra124 (Jetson TK1) # usb start starting USB... USB-1: USB EHCI 1.10 scanning bus 0 for devices... 1 USB Device(s) found USB-1: USB EHCI 1.10
(I notice both those lines have the same device ID rather than one being 0 and the other 1)
scanning bus 1 for devices... EHCI timed out on TD - token=0x80008d80 USB device not accepting new address (error=2) EHCI timed out on TD - token=0x80008d80
USB device not accepting new address (error=2)4 USB Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found Tegra124 (Jetson TK1) # usb tree USB device tree: +-1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller
+-1 Hub (480 Mb/s, 0mA)
(same issue there, although perhaps this is expected if USB devnum is per-controller now?)
| u-boot EHCI Host Controller | +-2 Hub (480 Mb/s, 100mA) | USB2.0 Hub | | 3 Hub (480 Mb/s, 100mA) | USB2.0 Hub | +-4 Mass Storage (480 Mb/s, 2mA) Sunplus Innovation Technology. USB to Serial-ATA bridge FF980813AF0000000000005FF16BFF
Seaboard/Springbank appears to have the same issue. Additionally, the flashing process spews a ton of:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x3f77a428 ERROR: v7_dcache_inval_range - stop address is not aligned - 0x3f77ac28
... and despite reporting an error during flash writing, the system boots, I don't know if this is anything related to the DM changes or something else though; I'll go check.
On 04/13/2015 10:27 AM, Stephen Warren wrote:
On 04/08/2015 09:11 PM, Simon Glass wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
On Jetson TK1, there's something up with USB.
...
... and here's u-boot-dm/next
Tegra124 (Jetson TK1) # usb start starting USB... USB-1: USB EHCI 1.10 scanning bus 0 for devices... 1 USB Device(s) found USB-1: USB EHCI 1.10
scanning bus 1 for devices... EHCI timed out on TD - token=0x80008d80 USB device not accepting new address (error=2) EHCI timed out on TD - token=0x80008d80
USB device not accepting new address (error=2)4 USB Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found
...
Seaboard/Springbank appears to have the same issue. Additionally, the flashing process spews a ton of:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x3f77a428 ERROR: v7_dcache_inval_range - stop address is not aligned - 0x3f77ac28
Both of those bisect to:
7bf0b2d00982 dm: usb: tegra: Move to driver model for USB
I wonder if the NAND issue is just a bug that's triggered by stack/data layout changes, and that commit tickles it?
For testing, it may be easier to load U-Boot into RAM that flash it every time. If so, since there's only 1 USB port, you'll need to use "usb reset" to re-scan that USB port. That will only work with the following patch, which I'll send in a minute:
diff --git a/include/configs/tegra-common-post.h b/include/configs/tegra-common-post.h index c3ad8beb903d..9ab58555378c 100644 --- a/include/configs/tegra-common-post.h +++ b/include/configs/tegra-common-post.h @@ -26,10 +26,11 @@ #define STDIN_KBD_KBC "" #endif
-#ifdef CONFIG_USB_KEYBOARD +#if defined(CONFIG_USB_KEYBOARD) && !defined(CONFIG_SPL_BUILD) #define STDIN_KBD_USB ",usbkbd" #define CONFIG_SYS_USB_EVENT_POLL #define CONFIG_PREBOOT "usb start" +#define CONFIG_SYS_STDIO_DEREGISTER #else #define STDIN_KBD_USB "" #endif
Hi Stephen,
On 13 April 2015 at 11:04, Stephen Warren swarren@wwwdotorg.org wrote:
On 04/13/2015 10:27 AM, Stephen Warren wrote:
On 04/08/2015 09:11 PM, Simon Glass wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
On Jetson TK1, there's something up with USB.
...
... and here's u-boot-dm/next
Tegra124 (Jetson TK1) # usb start starting USB... USB-1: USB EHCI 1.10 scanning bus 0 for devices... 1 USB Device(s) found USB-1: USB EHCI 1.10
scanning bus 1 for devices... EHCI timed out on TD - token=0x80008d80 USB device not accepting new address (error=2) EHCI timed out on TD - token=0x80008d80
USB device not accepting new address (error=2)4 USB Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found
I saw that too, and not just on Tegra. But in my testing it didn't happen on every run and it happened before and after switching to driver model. Can you check by running it 5 times?
I saw a report of this problem on the mailing list so figured it was unrelated. For now I can remove this patch from dm/next, but I'll wait to hear from you.
...
Seaboard/Springbank appears to have the same issue. Additionally, the flashing process spews a ton of:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x3f77a428 ERROR: v7_dcache_inval_range - stop address is not aligned - 0x3f77ac28
This is supposed to use alloc_priv() in drivers/core/device.c to allocate a DMA-aligned address. I wonder which buffer is causing this problem? I'll check it out on seaboard - I did most of my testing on Jetson only a sanity check on seaboard, so perhaps something broke in the meantime.
Both of those bisect to:
7bf0b2d00982 dm: usb: tegra: Move to driver model for USB
I wonder if the NAND issue is just a bug that's triggered by stack/data layout changes, and that commit tickles it?
Which NAND issue?
For testing, it may be easier to load U-Boot into RAM that flash it every time. If so, since there's only 1 USB port, you'll need to use "usb reset" to re-scan that USB port. That will only work with the following patch, which I'll send in a minute:
diff --git a/include/configs/tegra-common-post.h b/include/configs/tegra-common-post.h index c3ad8beb903d..9ab58555378c 100644 --- a/include/configs/tegra-common-post.h +++ b/include/configs/tegra-common-post.h @@ -26,10 +26,11 @@ #define STDIN_KBD_KBC "" #endif
-#ifdef CONFIG_USB_KEYBOARD +#if defined(CONFIG_USB_KEYBOARD) && !defined(CONFIG_SPL_BUILD) #define STDIN_KBD_USB ",usbkbd" #define CONFIG_SYS_USB_EVENT_POLL #define CONFIG_PREBOOT "usb start" +#define CONFIG_SYS_STDIO_DEREGISTER #else #define STDIN_KBD_USB "" #endif
Regards, Simon
On 04/13/2015 11:29 AM, Simon Glass wrote:
Hi Stephen,
On 13 April 2015 at 11:04, Stephen Warren swarren@wwwdotorg.org wrote:
On 04/13/2015 10:27 AM, Stephen Warren wrote:
On 04/08/2015 09:11 PM, Simon Glass wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
On Jetson TK1, there's something up with USB.
...
... and here's u-boot-dm/next
Tegra124 (Jetson TK1) # usb start starting USB... USB-1: USB EHCI 1.10 scanning bus 0 for devices... 1 USB Device(s) found USB-1: USB EHCI 1.10
scanning bus 1 for devices... EHCI timed out on TD - token=0x80008d80 USB device not accepting new address (error=2) EHCI timed out on TD - token=0x80008d80
USB device not accepting new address (error=2)4 USB Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found
I saw that too, and not just on Tegra. But in my testing it didn't happen on every run and it happened before and after switching to driver model. Can you check by running it 5 times?
I saw a report of this problem on the mailing list so figured it was unrelated. For now I can remove this patch from dm/next, but I'll wait to hear from you.
I already checked the bisect result 5 times on the bad and immediately preceding good commit.
...
Seaboard/Springbank appears to have the same issue. Additionally, the flashing process spews a ton of:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x3f77a428 ERROR: v7_dcache_inval_range - stop address is not aligned - 0x3f77ac28
This is supposed to use alloc_priv() in drivers/core/device.c to allocate a DMA-aligned address. I wonder which buffer is causing this problem? I'll check it out on seaboard - I did most of my testing on Jetson only a sanity check on seaboard, so perhaps something broke in the meantime.
It looks like this one in tegra_nand.c:nand_rw_page():
dma_prepare(buf, 1 << chip->page_shift, is_writing);
... which is odd since I thought that "buf" was simply the user-supplied buffer, incremented by the NAND page size each time. I'll trace through the code a bit more.
Both of those bisect to:
7bf0b2d00982 dm: usb: tegra: Move to driver model for USB
I wonder if the NAND issue is just a bug that's triggered by stack/data layout changes, and that commit tickles it?
Which NAND issue?
The cache alignment errors during NAND write.
Hi Stephen,
On 13 April 2015 at 11:36, Stephen Warren swarren@wwwdotorg.org wrote:
On 04/13/2015 11:29 AM, Simon Glass wrote:
Hi Stephen,
On 13 April 2015 at 11:04, Stephen Warren swarren@wwwdotorg.org wrote:
On 04/13/2015 10:27 AM, Stephen Warren wrote:
On 04/08/2015 09:11 PM, Simon Glass wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
On Jetson TK1, there's something up with USB.
...
... and here's u-boot-dm/next
Tegra124 (Jetson TK1) # usb start starting USB... USB-1: USB EHCI 1.10 scanning bus 0 for devices... 1 USB Device(s) found USB-1: USB EHCI 1.10
scanning bus 1 for devices... EHCI timed out on TD - token=0x80008d80 USB device not accepting new address (error=2) EHCI timed out on TD - token=0x80008d80
USB device not accepting new address (error=2)4 USB Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found
I saw that too, and not just on Tegra. But in my testing it didn't happen on every run and it happened before and after switching to driver model. Can you check by running it 5 times?
I saw a report of this problem on the mailing list so figured it was unrelated. For now I can remove this patch from dm/next, but I'll wait to hear from you.
I already checked the bisect result 5 times on the bad and immediately preceding good commit.
...
Seaboard/Springbank appears to have the same issue. Additionally, the flashing process spews a ton of:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x3f77a428 ERROR: v7_dcache_inval_range - stop address is not aligned - 0x3f77ac28
This is supposed to use alloc_priv() in drivers/core/device.c to allocate a DMA-aligned address. I wonder which buffer is causing this problem? I'll check it out on seaboard - I did most of my testing on Jetson only a sanity check on seaboard, so perhaps something broke in the meantime.
It looks like this one in tegra_nand.c:nand_rw_page():
dma_prepare(buf, 1 << chip->page_shift, is_writing);... which is odd since I thought that "buf" was simply the user-supplied buffer, incremented by the NAND page size each time. I'll trace through the code a bit more.
Both of those bisect to:
7bf0b2d00982 dm: usb: tegra: Move to driver model for USB
I wonder if the NAND issue is just a bug that's triggered by stack/data layout changes, and that commit tickles it?
Which NAND issue?
The cache alignment errors during NAND write.
Ah OK, I thought you were saying this was a USB issue. I can't see how the driver model updates would affect NAND except as you say, that the commit changes the data/bss section layout.
For now I'm going to drop this commit from dm/next, since it might take a bit of time to figure things out.
Regards, Simon
Hi Stephen,
On 13 April 2015 at 11:46, Simon Glass sjg@chromium.org wrote:
Hi Stephen,
On 13 April 2015 at 11:36, Stephen Warren swarren@wwwdotorg.org wrote:
On 04/13/2015 11:29 AM, Simon Glass wrote:
Hi Stephen,
On 13 April 2015 at 11:04, Stephen Warren swarren@wwwdotorg.org wrote:
On 04/13/2015 10:27 AM, Stephen Warren wrote:
On 04/08/2015 09:11 PM, Simon Glass wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
> Hi, > > I have quite a few patches queued up in the next branch of u-boot-dm, > ready for when the merge window options. > > If anyone has time and can give it a spin on their board, it would be > much > appreciated!
On Jetson TK1, there's something up with USB.
...
... and here's u-boot-dm/next
Tegra124 (Jetson TK1) # usb start starting USB... USB-1: USB EHCI 1.10 scanning bus 0 for devices... 1 USB Device(s) found USB-1: USB EHCI 1.10
scanning bus 1 for devices... EHCI timed out on TD - token=0x80008d80 USB device not accepting new address (error=2) EHCI timed out on TD - token=0x80008d80
USB device not accepting new address (error=2)4 USB Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found
I saw that too, and not just on Tegra. But in my testing it didn't happen on every run and it happened before and after switching to driver model. Can you check by running it 5 times?
I saw a report of this problem on the mailing list so figured it was unrelated. For now I can remove this patch from dm/next, but I'll wait to hear from you.
I already checked the bisect result 5 times on the bad and immediately preceding good commit.
...
Seaboard/Springbank appears to have the same issue. Additionally, the flashing process spews a ton of:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x3f77a428 ERROR: v7_dcache_inval_range - stop address is not aligned - 0x3f77ac28
This is supposed to use alloc_priv() in drivers/core/device.c to allocate a DMA-aligned address. I wonder which buffer is causing this problem? I'll check it out on seaboard - I did most of my testing on Jetson only a sanity check on seaboard, so perhaps something broke in the meantime.
It looks like this one in tegra_nand.c:nand_rw_page():
dma_prepare(buf, 1 << chip->page_shift, is_writing);... which is odd since I thought that "buf" was simply the user-supplied buffer, incremented by the NAND page size each time. I'll trace through the code a bit more.
Both of those bisect to:
7bf0b2d00982 dm: usb: tegra: Move to driver model for USB
I wonder if the NAND issue is just a bug that's triggered by stack/data layout changes, and that commit tickles it?
Which NAND issue?
The cache alignment errors during NAND write.
Ah OK, I thought you were saying this was a USB issue. I can't see how the driver model updates would affect NAND except as you say, that the commit changes the data/bss section layout.
For now I'm going to drop this commit from dm/next, since it might take a bit of time to figure things out.
I've pushed a new u-boot-dm/next if you'd like to try it.
Regards, Simon
On 04/13/2015 11:52 AM, Simon Glass wrote: ...
> On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote: >> I have quite a few patches queued up in the next branch of u-boot-dm, >> ready for when the merge window options. >> >> If anyone has time and can give it a spin on their board, it would be >> much >> appreciated!
...
I've pushed a new u-boot-dm/next if you'd like to try it.
(On Seaboard at least) this solves the two problems we were discussing: * Cache alignment issues during NAND writes. * Failure to enumerate some USB devices.
However, I just noticed that USB keyboard support doesn't work (On Seaboard at least). I've bisect this to:
6105422c50ee dm: usb: Move descriptor setup code into its own function
Hi Stephen,
On 13 April 2015 at 13:03, Stephen Warren swarren@wwwdotorg.org wrote:
On 04/13/2015 11:52 AM, Simon Glass wrote: ...
>> >> On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote: >>> >>> I have quite a few patches queued up in the next branch of >>> u-boot-dm, >>> ready for when the merge window options. >>> >>> If anyone has time and can give it a spin on their board, it would >>> be >>> much >>> appreciated!
...
I've pushed a new u-boot-dm/next if you'd like to try it.
(On Seaboard at least) this solves the two problems we were discussing:
- Cache alignment issues during NAND writes.
- Failure to enumerate some USB devices.
However, I just noticed that USB keyboard support doesn't work (On Seaboard at least). I've bisect this to:
6105422c50ee dm: usb: Move descriptor setup code into its own function
Interesting - there is a small change in that function which I thought was safe, but apparently not. I'll revert it and re-test later today, and let you know when it is ready.
Regards, Simon
Hi Stephen,
On 13 April 2015 at 14:17, Simon Glass sjg@chromium.org wrote:
Hi Stephen,
On 13 April 2015 at 13:03, Stephen Warren swarren@wwwdotorg.org wrote:
On 04/13/2015 11:52 AM, Simon Glass wrote: ...
>>> >>> On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote: >>>> >>>> I have quite a few patches queued up in the next branch of >>>> u-boot-dm, >>>> ready for when the merge window options. >>>> >>>> If anyone has time and can give it a spin on their board, it would >>>> be >>>> much >>>> appreciated!
...
I've pushed a new u-boot-dm/next if you'd like to try it.
(On Seaboard at least) this solves the two problems we were discussing:
- Cache alignment issues during NAND writes.
- Failure to enumerate some USB devices.
However, I just noticed that USB keyboard support doesn't work (On Seaboard at least). I've bisect this to:
6105422c50ee dm: usb: Move descriptor setup code into its own function
Interesting - there is a small change in that function which I thought was safe, but apparently not. I'll revert it and re-test later today, and let you know when it is ready.
Actually that was another patch I was thinking off. I tested the series with two different keyboards at the time (which is why I had to add the later patch to move USB keyboards over to drive model), but obviously I did something wrong as when I test it now, it does not work. Oh dear.
I fixed up the three refactoring patches and have resent them to the list. I've also updated u-boot-dm/next if you have time to test again. Both keyboards work for me on seaboard now.
I did consider just adding a fixup patch to the end, but I don't like the idea of USB keyboard being broken for many patches if someone later bisects the tree.
Thanks for helping test this. I suspect there might be other problems that will show up when more people try it out, but there is plenty of time to deal with that.
Regards, Simon
Hi,
On 13 April 2015 at 21:25, Simon Glass sjg@chromium.org wrote:
Hi Stephen,
On 13 April 2015 at 14:17, Simon Glass sjg@chromium.org wrote:
Hi Stephen,
On 13 April 2015 at 13:03, Stephen Warren swarren@wwwdotorg.org wrote:
On 04/13/2015 11:52 AM, Simon Glass wrote: ...
>>>> >>>> On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote: >>>>> >>>>> I have quite a few patches queued up in the next branch of >>>>> u-boot-dm, >>>>> ready for when the merge window options. >>>>> >>>>> If anyone has time and can give it a spin on their board, it would >>>>> be >>>>> much >>>>> appreciated!
...
I've pushed a new u-boot-dm/next if you'd like to try it.
(On Seaboard at least) this solves the two problems we were discussing:
- Cache alignment issues during NAND writes.
- Failure to enumerate some USB devices.
However, I just noticed that USB keyboard support doesn't work (On Seaboard at least). I've bisect this to:
6105422c50ee dm: usb: Move descriptor setup code into its own function
Interesting - there is a small change in that function which I thought was safe, but apparently not. I'll revert it and re-test later today, and let you know when it is ready.
Actually that was another patch I was thinking off. I tested the series with two different keyboards at the time (which is why I had to add the later patch to move USB keyboards over to drive model), but obviously I did something wrong as when I test it now, it does not work. Oh dear.
This may be because I did most of my testing with XHCI which uses a different code path. The code sequence of USB init is quite complex, but it seems that most of this complexity is unfortunately needed for the various cases that come up.
Regards, Simon
On 04/08/2015 09:11 PM, Simon Glass wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
I assume this has been merged into u-boot/master now. FWIW, commit d8c1d5d5fb6e "Merge branch 'buildman' of git://git.denx.de/u-boot-x86" from there seems to work fine on the RPi.
Hi Stephen,
On 24 April 2015 at 22:46, Stephen Warren swarren@nvidia.com wrote:
On 04/08/2015 09:11 PM, Simon Glass wrote:
(Correcting address for Masahiro, sorry)
On 8 April 2015 at 21:07, Simon Glass sjg@chromium.org wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
I assume this has been merged into u-boot/master now. FWIW, commit d8c1d5d5fb6e "Merge branch 'buildman' of git://git.denx.de/u-boot-x86" from there seems to work fine on the RPi.
Thanks for the follow-up, good to hear.
Regards, Simon
Hello Simon,
On 04/09/2015 05:07 AM, Simon Glass wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
I tested this on Odroid U3. It looks that everything works fine. I see that ehci_hcd_init() is not used, then where can we call the board_usb_init()?
Best regards,
Hi Przemyslaw,
On 9 April 2015 at 01:55, Przemyslaw Marczak p.marczak@samsung.com wrote:
Hello Simon,
On 04/09/2015 05:07 AM, Simon Glass wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
I tested this on Odroid U3. It looks that everything works fine. I see that ehci_hcd_init() is not used, then where can we call the board_usb_init()?
Thanks for testing.
Can board_usb_init() be called from within the board_init() code instead? Or are you trying to avoid doing this init unless USB is actually used? If so, then I'll need to have a think about it.
Regards, Simon
Hello Simon,
On 04/10/2015 07:40 PM, Simon Glass wrote:
Hi Przemyslaw,
On 9 April 2015 at 01:55, Przemyslaw Marczak p.marczak@samsung.com wrote:
Hello Simon,
On 04/09/2015 05:07 AM, Simon Glass wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
I tested this on Odroid U3. It looks that everything works fine. I see that ehci_hcd_init() is not used, then where can we call the board_usb_init()?
Thanks for testing.
Can board_usb_init() be called from within the board_init() code instead? Or are you trying to avoid doing this init unless USB is actually used? If so, then I'll need to have a think about it.
Regards, Simon
I noticed, that after changes the USB command doesn't recognize the mass storage device. I haven't too much time for checking it deeper. I will check it on Monday and give you a response.
Best regards,
Hi Przemyslaw,
On 10 April 2015 at 11:50, Przemyslaw Marczak p.marczak@samsung.com wrote:
Hello Simon,
On 04/10/2015 07:40 PM, Simon Glass wrote:
Hi Przemyslaw,
On 9 April 2015 at 01:55, Przemyslaw Marczak p.marczak@samsung.com wrote:
Hello Simon,
On 04/09/2015 05:07 AM, Simon Glass wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
I tested this on Odroid U3. It looks that everything works fine. I see that ehci_hcd_init() is not used, then where can we call the board_usb_init()?
Thanks for testing.
Can board_usb_init() be called from within the board_init() code instead? Or are you trying to avoid doing this init unless USB is actually used? If so, then I'll need to have a think about it.
Regards, Simon
I noticed, that after changes the USB command doesn't recognize the mass storage device. I haven't too much time for checking it deeper. I will check it on Monday and give you a response.
OK thanks. You can also try removing CONFIG_DM_USB as a comparison. I'm happy to switch this back to not use driver model until any problems are resolved.
Regards, Simon
Hello,
On 04/10/2015 07:57 PM, Simon Glass wrote:
Hi Przemyslaw,
On 10 April 2015 at 11:50, Przemyslaw Marczak p.marczak@samsung.com wrote:
Hello Simon,
On 04/10/2015 07:40 PM, Simon Glass wrote:
Hi Przemyslaw,
On 9 April 2015 at 01:55, Przemyslaw Marczak p.marczak@samsung.com wrote:
Hello Simon,
On 04/09/2015 05:07 AM, Simon Glass wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
I tested this on Odroid U3. It looks that everything works fine. I see that ehci_hcd_init() is not used, then where can we call the board_usb_init()?
Thanks for testing.
Can board_usb_init() be called from within the board_init() code instead? Or are you trying to avoid doing this init unless USB is actually used? If so, then I'll need to have a think about it.
Regards, Simon
I noticed, that after changes the USB command doesn't recognize the mass storage device. I haven't too much time for checking it deeper. I will check it on Monday and give you a response.
OK thanks. You can also try removing CONFIG_DM_USB as a comparison. I'm happy to switch this back to not use driver model until any problems are resolved.
Regards, Simon
Ok, I will also check this. Or if find the time, I will fix the storage issue for dm-usb.
Best regards,
Hi Prazemyslaw,
On 10 April 2015 at 12:08, Przemyslaw Marczak p.marczak@samsung.com wrote:
Hello,
On 04/10/2015 07:57 PM, Simon Glass wrote:
Hi Przemyslaw,
On 10 April 2015 at 11:50, Przemyslaw Marczak p.marczak@samsung.com wrote:
Hello Simon,
On 04/10/2015 07:40 PM, Simon Glass wrote:
Hi Przemyslaw,
On 9 April 2015 at 01:55, Przemyslaw Marczak p.marczak@samsung.com wrote:
Hello Simon,
On 04/09/2015 05:07 AM, Simon Glass wrote:
Hi,
I have quite a few patches queued up in the next branch of u-boot-dm, ready for when the merge window options.
If anyone has time and can give it a spin on their board, it would be much appreciated!
Regards, Simon
I tested this on Odroid U3. It looks that everything works fine. I see that ehci_hcd_init() is not used, then where can we call the board_usb_init()?
Thanks for testing.
Can board_usb_init() be called from within the board_init() code instead? Or are you trying to avoid doing this init unless USB is actually used? If so, then I'll need to have a think about it.
Regards, Simon
I noticed, that after changes the USB command doesn't recognize the mass storage device. I haven't too much time for checking it deeper. I will check it on Monday and give you a response.
OK thanks. You can also try removing CONFIG_DM_USB as a comparison. I'm happy to switch this back to not use driver model until any problems are resolved.
Regards, Simon
Ok, I will also check this. Or if find the time, I will fix the storage issue for dm-usb.
Thanks. Just a note on my testing. I used a power hub with 3 USB flash sticks and a USB Ethernet dongle. Also I plugged a unpowered hub into the powered hub, with its own USB stick. I tried this on snow/pit both with and without DM_USB.
For mass storage the detection method is different (you now register drivers which can handle the various interface classes, etc.) but the effect is intended to be the same. But there may be an error somewhere.
Regards, Simon
Hello Simon,
On 04/13/2015 04:31 PM, Simon Glass wrote:
Hi Prazemyslaw,
On 10 April 2015 at 12:08, Przemyslaw Marczak p.marczak@samsung.com wrote:
Hello,
On 04/10/2015 07:57 PM, Simon Glass wrote:
Hi Przemyslaw,
On 10 April 2015 at 11:50, Przemyslaw Marczak p.marczak@samsung.com wrote:
Hello Simon,
On 04/10/2015 07:40 PM, Simon Glass wrote:
Hi Przemyslaw,
On 9 April 2015 at 01:55, Przemyslaw Marczak p.marczak@samsung.com wrote:
Hello Simon,
On 04/09/2015 05:07 AM, Simon Glass wrote: > > > > Hi, > > I have quite a few patches queued up in the next branch of u-boot-dm, > ready > for when the merge window options. > > If anyone has time and can give it a spin on their board, it would be > much > appreciated! > > Regards, > Simon >
I tested this on Odroid U3. It looks that everything works fine. I see that ehci_hcd_init() is not used, then where can we call the board_usb_init()?
Thanks for testing.
Can board_usb_init() be called from within the board_init() code instead? Or are you trying to avoid doing this init unless USB is actually used? If so, then I'll need to have a think about it.
Regards, Simon
I noticed, that after changes the USB command doesn't recognize the mass storage device. I haven't too much time for checking it deeper. I will check it on Monday and give you a response.
OK thanks. You can also try removing CONFIG_DM_USB as a comparison. I'm happy to switch this back to not use driver model until any problems are resolved.
Regards, Simon
Ok, I will also check this. Or if find the time, I will fix the storage issue for dm-usb.
Thanks. Just a note on my testing. I used a power hub with 3 USB flash sticks and a USB Ethernet dongle. Also I plugged a unpowered hub into the powered hub, with its own USB stick. I tried this on snow/pit both with and without DM_USB.
For mass storage the detection method is different (you now register drivers which can handle the various interface classes, etc.) but the effect is intended to be the same. But there may be an error somewhere.
Regards, Simon
Sorry, I haven't time for this today. I hope to check this tomorrow.
Best regards,
participants (5)
-
Bin Meng -
Przemyslaw Marczak -
Simon Glass -
Stephen Warren -
Stephen Warren