2023.04 U-Boot Kirkwood - Pogo V4
Posted by bodhi
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 22, 2023 03:11PM |
Registered: 4 years ago Posts: 60 |
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 22, 2023 03:51PM |
Admin Registered: 13 years ago Posts: 18,900 |
> After having the same issues as @dhargens with
> 6.3.5, I can confirm that 6.3.8 is working on the
> Pogoplug V4. Thanks for the continuing help!
Cool!
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> 6.3.5, I can confirm that 6.3.8 is working on the
> Pogoplug V4. Thanks for the continuing help!
Cool!
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 22, 2023 04:34PM |
Registered: 1 year ago Posts: 96 |
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 22, 2023 04:47PM |
Admin Registered: 13 years ago Posts: 18,900 |
dhargens,
Cool! now try the CPU LED trigger.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Cool! now try the CPU LED trigger.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 22, 2023 05:28PM |
Registered: 1 year ago Posts: 96 |
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 22, 2023 07:28PM |
Registered: 1 year ago Posts: 96 |
I'm seeing something I'd seen before, but assumed it was related to the issue in mainline kernel.
I had used a Cruzer Ultra 3.1 in the back port and it worked well. No errors. Then I couldn't leave things well enough alone, so I created another rootfs on a Cruzer Fit 2.0 and put it in the top port. When it booted, it showed the following:
I'll research this further and if it continues I'll let you know. It may be related to heat since these things get REALLY hot when setting them up, and maybe also the orion errors I see when I put a USB 3.1 in the top port.
I had used a Cruzer Ultra 3.1 in the back port and it worked well. No errors. Then I couldn't leave things well enough alone, so I created another rootfs on a Cruzer Fit 2.0 and put it in the top port. When it booted, it showed the following:
U-Boot 2023.04-tld-1 (Jun 11 2023 - 16:24:44 -0700) Pogoplug V4 SoC: Kirkwood 88F6192_A1 Model: Cloud Engines PogoPlug Series 4 DRAM: 128 MiB Core: 20 devices, 16 uclasses, devicetree: separate NAND: 128 MiB MMC: mvsdio@90000: 0 Loading Environment from NAND... OK Resetting console stdin/stdout/stderr to serial... In: serial Out: serial Err: serial pcie0.0: Link up Net: eth0: ethernet-controller@72000 Hit any key to stop autoboot: 0 Initializing devices... resetting USB... Bus ehci@50000: USB EHCI 1.00 Bus xhci_pci: Register 400081f NbrPorts 4 Starting the controller USB XHCI 1.00 scanning bus ehci@50000 for devices... 2 USB Device(s) found scanning bus xhci_pci for devices... XHCI timeout on event type 33... cannot recover. BUG at drivers/usb/host/xhci-ring.c:496/xhci_wait_for_event()! BUG! resetting ...It did this 8 times, then decided to clear up, stutter a moment, and then boot normally. It hesitated on the 9th attempt with the following:
Starting the controller
USB XHCI 1.00
scanning bus ehci@50000 for devices... 2 USB Device(s) found
scanning bus xhci_pci for devices... 1 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
resetting USB...
Bus ehci@50000: USB EHCI 1.00
Bus xhci_pci: Register 400081f NbrPorts 4
Starting the controller
USB XHCI 1.00
scanning bus ehci@50000 for devices... 2 USB Device(s) found
scanning bus xhci_pci for devices... 1 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Loading envs from usb 0...
[normal boot output from here on...]
and then it continued on and completed the boot. I don't know if it's important that it showed "Starting the controller" twice in that segment, but the first time it reset the USB and didn't on the 2nd occurrence.
I'll research this further and if it continues I'll let you know. It may be related to heat since these things get REALLY hot when setting them up, and maybe also the orion errors I see when I put a USB 3.1 in the top port.
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 22, 2023 07:39PM |
Admin Registered: 13 years ago Posts: 18,900 |
Quote
I had used a Cruzer Ultra 3.1 in the back port and it worked well. No errors. Then I couldn't leave things well enough alone, so I created another rootfs on a Cruzer Fit 2.0 and put it in the top port.
Repeat this test configuration. Interrupt serial console countdown and
usb reset usb part usb info
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 22, 2023 07:58PM |
Registered: 1 year ago Posts: 96 |
bodhi Wrote:
-------------------------------------------------------
Here's the outputs:
I'll try it on my next 'hard work' session on the thumb if it errors and see what it says then.
-------------------------------------------------------
Quote
Repeat this test configuration. Interrupt serial console countdown and
usb reset usb part usb info
Here's the outputs:
Pogo_V4> usb reset
resetting USB...
Bus ehci@50000: USB EHCI 1.00
Bus xhci_pci: Register 400081f NbrPorts 4
Starting the controller
USB XHCI 1.00
scanning bus ehci@50000 for devices... 2 USB Device(s) found
scanning bus xhci_pci for devices... 1 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Pogo_V4> usb part Partition Map for USB device 0 -- Partition Type: DOS Part Start Sector Num Sectors UUID Type 1 2048 30029824 ab08c3e4-01 83
Pogo_V4> usb info
1: Hub, USB Revision 2.0
- u-boot EHCI Host Controller
- Class: Hub
- PacketSize: 64 Configurations: 1
- Vendor: 0x0000 Product 0x0000 Version 1.0
Configuration: 1
- Interfaces: 1 Self Powered 0mA
Interface: 0
- Alternate Setting 0, Endpoints: 1
- Class Hub
- Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
2: Mass Storage, USB Revision 2.0
- SanDisk' Cruzer Fit 03022208021123185156
- Class: (from Interface) Mass Storage
- PacketSize: 64 Configurations: 1
- Vendor: 0x0781 Product 0x5571 Version 1.0
Configuration: 1
- Interfaces: 1 Bus Powered 200mA
Interface: 0
- Alternate Setting 0, Endpoints: 2
- Class Mass Storage, Transp. SCSI, Bulk only
- Endpoint 1 In Bulk MaxPacket 512
- Endpoint 2 Out Bulk MaxPacket 512
1: Hub, USB Revision 3.0
- U-Boot XHCI Host Controller
- Class: Hub
- PacketSize: 512 Configurations: 1
- Vendor: 0x0000 Product 0x0000 Version 1.0
Configuration: 1
- Interfaces: 1 Self Powered 0mA
Interface: 0
- Alternate Setting 0, Endpoints: 1
- Class Hub
- Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
It booted after that with no errors. It was cooler now, so maybe that's why it had no errors.
I'll try it on my next 'hard work' session on the thumb if it errors and see what it says then.
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 22, 2023 10:06PM |
Admin Registered: 13 years ago Posts: 18,900 |
The log does not make sense. It indicates that the only USB drive attached is the Cruzer Fit.
WIth a Cruzer Ultra 3.1 in the back port, and a Cruzer Fit 2.0 in the top port. You should see 2 USB storage drives.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
WIth a Cruzer Ultra 3.1 in the back port, and a Cruzer Fit 2.0 in the top port. You should see 2 USB storage drives.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 22, 2023 10:26PM |
Registered: 1 year ago Posts: 96 |
Sorry if I was unclear - I only put one drive in at a time. I thought I'd read somewhere here that (as I understand it) you can only have one drive at a time with the 'rootfs' label or it gets confused, so I only ever have one installed at a time. Besides, I don't know which drive loads first, though I'd suspect it's the top port.
I meant to say that I made a rootfs on a Ultra 3.1 and it worked on the back port, then I created rootfs on a Fit 2.0, removed the 3.1 and put the 2.0 in the top port. (a 3.1 drive throws loads of errors in the top port, so I only put 3s in the back and 2s in the top. most of the time 2s work fine in the top.)
Reviewing my earlier post, I can see that I forgot the "I removed the 3.1 when I installed the 2.0" part. Apologies for the confusion.
I can install both in the V4 and see what it says if you'd like. Easy enough to do.
Edited 1 time(s). Last edit at 06/22/2023 10:27PM by dhargens.
I meant to say that I made a rootfs on a Ultra 3.1 and it worked on the back port, then I created rootfs on a Fit 2.0, removed the 3.1 and put the 2.0 in the top port. (a 3.1 drive throws loads of errors in the top port, so I only put 3s in the back and 2s in the top. most of the time 2s work fine in the top.)
Reviewing my earlier post, I can see that I forgot the "I removed the 3.1 when I installed the 2.0" part. Apologies for the confusion.
I can install both in the V4 and see what it says if you'd like. Easy enough to do.
Edited 1 time(s). Last edit at 06/22/2023 10:27PM by dhargens.
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 22, 2023 10:47PM |
Admin Registered: 13 years ago Posts: 18,900 |
> Sorry if I was unclear - I only put one drive in
> at a time. I thought I'd read somewhere here that
> (as I understand it) you can only have one drive
> at a time with the 'rootfs' label or it gets
> confused, so I only ever have one installed at a
> time.
Right! if there are 2 drives with rootfs label, then we cannot be sure which will be loaded by the kernel.
> Besides, I don't know which drive loads
> first, though I'd suspect it's the top port.
Most of the time the drive that's near to the Ethernet port is enumerated first. But that's just an empirical observation, there is no guarantee.
> a 3.1 drive throws
> loads of errors in the top port,
That's is expected with this box. I think it is the old controller FW that cannot deal with USB 3.0 properly.
So to test the 2 drives configuration you could juts plug in a non-rootfs USB 2.0 drive on the top port. Or if you plug in a USB 3.0 hub to the top port, then it will work regardless which type of drive attached to the hub (the label rule still applies).
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> at a time. I thought I'd read somewhere here that
> (as I understand it) you can only have one drive
> at a time with the 'rootfs' label or it gets
> confused, so I only ever have one installed at a
> time.
Right! if there are 2 drives with rootfs label, then we cannot be sure which will be loaded by the kernel.
> Besides, I don't know which drive loads
> first, though I'd suspect it's the top port.
Most of the time the drive that's near to the Ethernet port is enumerated first. But that's just an empirical observation, there is no guarantee.
> a 3.1 drive throws
> loads of errors in the top port,
That's is expected with this box. I think it is the old controller FW that cannot deal with USB 3.0 properly.
So to test the 2 drives configuration you could juts plug in a non-rootfs USB 2.0 drive on the top port. Or if you plug in a USB 3.0 hub to the top port, then it will work regardless which type of drive attached to the hub (the label rule still applies).
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 23, 2023 10:28AM |
Registered: 4 years ago Posts: 60 |
dhargens Wrote:
-------------------------------------------------------
>It may be related to heat since
> these things get REALLY hot when setting them up,
> and maybe also the orion errors I see when I put a
> USB 3.1 in the top port.
I was happy to see this observation as I have experienced the same thing and was worried it was my device. As you said, the thing was really hot during setup and I was afraid I was going to fry something!
-------------------------------------------------------
>It may be related to heat since
> these things get REALLY hot when setting them up,
> and maybe also the orion errors I see when I put a
> USB 3.1 in the top port.
I was happy to see this observation as I have experienced the same thing and was worried it was my device. As you said, the thing was really hot during setup and I was afraid I was going to fry something!
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 23, 2023 02:32PM |
Admin Registered: 13 years ago Posts: 18,900 |
This plug and the Dockstar need special care for ventilation. You should place it sideway on its edge, or at the minimum use 4 cloth/silicone feet to raise it higher above the surface.
All my Pogo V4, Dockstar, GoFlex Home/Net plugs have feet (a few cm high). And the Pogo V4's are placed sideway to save space and for better ventilation.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
All my Pogo V4, Dockstar, GoFlex Home/Net plugs have feet (a few cm high). And the Pogo V4's are placed sideway to save space and for better ventilation.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 23, 2023 05:56PM |
Registered: 1 year ago Posts: 96 |
- My testing scenarios -
uboot ver: U-Boot 2023.04-tld-1 (Jun 11 2023 - 16:24:44 -0700)
Note: Power is removed & reapplied at start of each numbered scenario, but not in middle of tests.
1. Booting with a Cruzer Fit 2.0 kernel 5.13.6 in the top, and a massive powered hard drive (Big Damn HD, unknown format, but not rootfs) in a rear port.
Constant recycling with "BUG" errors below.
I interrupt the boot as suggested, and issue the commands to check things.
Remove the BDHD and it boots successfully.
2. Booting with a Cruzer Fit 2.0 (5.13.6) in the top, and a Cruzer Ultra 3.1 (6.3.8) in a rear port. Both drives have a rootfs system on them.
Constant recycling with "BUG" errors shown above.
Remove the 3.1 drive, it clears and boots successfully.
3. Booting with the Cruzer Ultra 3.1 (6.3.8) in a rear port (due to uboot 2023).
It boots successfully, as expected.
Plugging in the rootfs 2.0 (5.13.6) drive in the top shows up in 'lsblk' normally.
Plugging the BDHD in the remaining back port does NOT show up in 'lsblk'.
Removing 2.0 (top) and leaving the BDHD in the other rear port shows up in 'lsblk'.
4. Booting with the Cruzer Ultra 3.1 (6.3.8) in a rear port and another Ultra 3.1 in the other rear port (formatted FAT32).
It boots successfully.
5. Booting with the Cruzer Ultra 3.1 (6.3.8) in a rear port and the BDHD in the other rear port (unknown format).
It boots successfully, and both show in 'lsblk'.
Plug a 2.0 (FAT32) in the top and it's seen in 'lsblk'.
Reboot and it breaks (cycling). Removing the BDHD does NOT clear the issue.
Plugging the BDHD back in and then removing the 2.0 (FAT32) clears and boots normally.
6. Booting with the Cruzer Ultra 3.1 (6.3.8) in a rear port, another Ultra 3.1 in the other rear port (formatted FAT32) and a FAT32 2.0 drive in the top shows constant recycling with "BUG" errors shown above.
Remove the 2.0 FAT32 drive, it clears and boots successfully.
Summary, as I see it:
5.13 can't boot with the BDHD in place. It also can't see all the drives properly.
6.3.8 can see all of the drives - it just can't boot if fully populated.
The top USB port must be pretty weak, as bodhi has inferred in the past. Dunno how it worked in the first place, but I guess they focused on 3.5" hard drives in the SATA port so who cared?
Thoughts on these test? Any other tests I can perform, or commands I can issue? I can try with uboot 2017 on another device or kernel 6.2 if it helps troubleshoot.
uboot ver: U-Boot 2023.04-tld-1 (Jun 11 2023 - 16:24:44 -0700)
Note: Power is removed & reapplied at start of each numbered scenario, but not in middle of tests.
1. Booting with a Cruzer Fit 2.0 kernel 5.13.6 in the top, and a massive powered hard drive (Big Damn HD, unknown format, but not rootfs) in a rear port.
Constant recycling with "BUG" errors below.
I interrupt the boot as suggested, and issue the commands to check things.
Pogo_V4> usb part USB is stopped. Please issue 'usb start' first. Pogo_V4> usb info USB is stopped. Please issue 'usb start' first. Pogo_V4> usb reset resetting USB... Bus ehci@50000: USB EHCI 1.00 Bus xhci_pci: Register 400081f NbrPorts 4 Starting the controller USB XHCI 1.00 scanning bus ehci@50000 for devices... 2 USB Device(s) found scanning bus xhci_pci for devices... XHCI timeout on event type 33... cannot recover. BUG at drivers/usb/host/xhci-ring.c:496/xhci_wait_for_event()! BUG! resetting ... U-Boot 2023.04-tld-1 (Jun 11 2023 - 16:24:44 -0700) Pogoplug V4 ...etc, recyclingThe command 'usb start' does the same as 'reset' and starts the cycling again.
Remove the BDHD and it boots successfully.
2. Booting with a Cruzer Fit 2.0 (5.13.6) in the top, and a Cruzer Ultra 3.1 (6.3.8) in a rear port. Both drives have a rootfs system on them.
Constant recycling with "BUG" errors shown above.
Remove the 3.1 drive, it clears and boots successfully.
3. Booting with the Cruzer Ultra 3.1 (6.3.8) in a rear port (due to uboot 2023).
It boots successfully, as expected.
Plugging in the rootfs 2.0 (5.13.6) drive in the top shows up in 'lsblk' normally.
Plugging the BDHD in the remaining back port does NOT show up in 'lsblk'.
Removing 2.0 (top) and leaving the BDHD in the other rear port shows up in 'lsblk'.
4. Booting with the Cruzer Ultra 3.1 (6.3.8) in a rear port and another Ultra 3.1 in the other rear port (formatted FAT32).
It boots successfully.
5. Booting with the Cruzer Ultra 3.1 (6.3.8) in a rear port and the BDHD in the other rear port (unknown format).
It boots successfully, and both show in 'lsblk'.
Plug a 2.0 (FAT32) in the top and it's seen in 'lsblk'.
Reboot and it breaks (cycling). Removing the BDHD does NOT clear the issue.
Plugging the BDHD back in and then removing the 2.0 (FAT32) clears and boots normally.
6. Booting with the Cruzer Ultra 3.1 (6.3.8) in a rear port, another Ultra 3.1 in the other rear port (formatted FAT32) and a FAT32 2.0 drive in the top shows constant recycling with "BUG" errors shown above.
Remove the 2.0 FAT32 drive, it clears and boots successfully.
Summary, as I see it:
5.13 can't boot with the BDHD in place. It also can't see all the drives properly.
6.3.8 can see all of the drives - it just can't boot if fully populated.
The top USB port must be pretty weak, as bodhi has inferred in the past. Dunno how it worked in the first place, but I guess they focused on 3.5" hard drives in the SATA port so who cared?
Thoughts on these test? Any other tests I can perform, or commands I can issue? I can try with uboot 2017 on another device or kernel 6.2 if it helps troubleshoot.
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 23, 2023 07:43PM |
Admin Registered: 13 years ago Posts: 18,900 |
resetting USB... Bus ehci@50000: USB EHCI 1.00 Bus xhci_pci: Register 400081f NbrPorts 4 Starting the controller USB XHCI 1.00 scanning bus ehci@50000 for devices... 2 USB Device(s) found scanning bus xhci_pci for devices... XHCI timeout on event type 33... cannot recover. BUG at drivers/usb/host/xhci-ring.c:496/xhci_wait_for_event()! BUG! resetting ...
Looks like there is a problem in mainline u-boot somewhere. The XHCI PCI driver (for USB 3.0) does not coexist well with the ECHI driver (for USB 2.0).
So for now do what work. Use either of these combinations when booting.
- Rear 2x ports (USB 3.0) and the SATA slot, MMC slot.
- Top port (USB 2.0) and the SATA slot, MMC slot.
After it boots, then plug in other USB drives if needed and remove them afterward.
It is apparently an issue with the combo of these 2 differrent controllers.
When I have time, I'll try this booting scenario with the NSA325.
And BTW, this has nothing to do with the kernel. Currenty, with the Kirkwood kernel, if a drive has problemduring boot, then the kernel won't see it. However, if the drive is OK, but not enumerated, the kernel will. This is a subtle difference between Kirkwood and Armada kernels (need a long explanation that's really is not too relevant to go into now).
IOW, Kernel 5.13 vs 6.3.8 is a red herring.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 2 time(s). Last edit at 06/23/2023 10:24PM by bodhi.
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 23, 2023 09:47PM |
Admin Registered: 13 years ago Posts: 18,900 |
OK. I've invalidated test 2 of your tests.
This test has the Sandisk Ultra Fit 16GB (USB 3.0) in the rear port, and Sandisk Cruzer Fit 8GB (USB 2.0) in the top port.
(Serial Number blanked out with xxxx)
Kernel boot log
And in Debian
# df -h
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Quote
2. Booting with a Cruzer Fit 2.0 (5.13.6) in the top, and a Cruzer Ultra 3.1 (6.3.8) in a rear port. Both drives have a rootfs system on them.
Constant recycling with "BUG" errors shown above.
Remove the 3.1 drive, it clears and boots successfully.
This test has the Sandisk Ultra Fit 16GB (USB 3.0) in the rear port, and Sandisk Cruzer Fit 8GB (USB 2.0) in the top port.
(Serial Number blanked out with xxxx)
U-Boot 2023.04-tld-1 (Jun 11 2023 - 16:24:44 -0700)
Pogoplug V4
SoC: Kirkwood 88F6192_A1
Model: Cloud Engines PogoPlug Series 4
DRAM: 128 MiB
Core: 20 devices, 16 uclasses, devicetree: separate
NAND: 128 MiB
MMC: mvsdio@90000: 0
Loading Environment from NAND... OK
Resetting console stdin/stdout/stderr to serial...
In: serial
Out: serial
Err: serial
pcie0.0: Link up
Net: eth0: ethernet-controller@72000
Hit any key to stop autoboot: 0
Pogo_V4> usb reset
resetting USB...
Bus ehci@50000: USB EHCI 1.00
Bus xhci_pci: Register 400081f NbrPorts 4
Starting the controller
USB XHCI 1.00
scanning bus ehci@50000 for devices... 2 USB Device(s) found
scanning bus xhci_pci for devices... 2 USB Device(s) found
scanning usb for storage devices... 2 Storage Device(s) found
Pogo_V4> usb part
Partition Map for USB device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type
1 2048 15631360 31c34037-01 83 Boot
Partition Map for USB device 1 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type
1 2048 30029202 ff40d6b1-01 83 Boot
Pogo_V4> usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Mass Storage (480 Mb/s, 200mA)
SanDisk Cruzer Fit 4C532000051xxxxxxx
1 Hub (5 Gb/s, 0mA)
| U-Boot XHCI Host Controller
|
+-2 Mass Storage (5 Gb/s, 224mA)
SanDisk Ultra Fit 4C53100156082xxxxxx
Pogo_V4>
Kernel boot log
[ 9.457957][ T8] scsi 2:0:0:0: Direct-Access SanDisk Cruzer Fit 1.22 PQ: 0 ANSI: 5 [ 9.477922][ T28] sd 2:0:0:0: [sda] 15633408 512-byte logical blocks: (8.00 GB/7.45 GiB) [ 9.493988][ T28] sd 2:0:0:0: [sda] Write Protect is off [ 9.504997][ T109] "cryptomgr_test" (109) uses obsolete ecb(arc4) skcipher [ 9.512495][ T28] sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 9.538495][ T8] scsi 3:0:0:0: Direct-Access SanDisk Ultra Fit 1.00 PQ: 0 ANSI: 6 [ 9.551458][ T28] sda: sda1 [ 9.556429][ T28] sd 2:0:0:0: [sda] Attached SCSI removable disk [ 9.566807][ T19] sd 3:0:0:0: [sdb] 30031250 512-byte logical blocks: (15.4 GB/14.3 GiB) [ 9.578899][ T19] sd 3:0:0:0: [sdb] Write Protect is off [ 9.596613][ T19] sd 3:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 9.624876][ T19] sdb: sdb1 [ 9.637633][ T19] sd 3:0:0:0: [sdb] Attached SCSI removable disk
And in Debian
# df -h
Filesystem Size Used Avail Use% Mounted on udev 50M 0 50M 0% /dev tmpfs 11M 1.3M 9.4M 13% /run /dev/sdb1 14G 9.2G 4.1G 70% / tmpfs 5.0M 4.0K 5.0M 1% /run/lock /dev/sda1 7.3G 4.3G 2.7G 62% /media/DATA tmpfs 22M 0 22M 0% /dev/shm tmpfs 54M 1.9M 52M 4% /tmp
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 23, 2023 10:49PM |
Registered: 1 year ago Posts: 96 |
Just tried it again, and here's the setup:
16G Fit 2.0 in the top port (rootfs label + kernel 5.13.6)
64G Ultra "SanDisk 3.2Gen1" in the rear port (rootfs label + kernel 6.3.8)
If this is how it looks when there's 2 labeled 'rootfs' when it boots, then that makes sense.
I don't see the 2nd test that you've invalidated.
16G Fit 2.0 in the top port (rootfs label + kernel 5.13.6)
64G Ultra "SanDisk 3.2Gen1" in the rear port (rootfs label + kernel 6.3.8)
U-Boot 2023.04-tld-1 (Jun 11 2023 - 16:24:44 -0700) Pogoplug V4 SoC: Kirkwood 88F6192_A1 Model: Cloud Engines PogoPlug Series 4 DRAM: 128 MiB Core: 20 devices, 16 uclasses, devicetree: separate NAND: 128 MiB MMC: mvsdio@90000: 0 Loading Environment from NAND... OK Resetting console stdin/stdout/stderr to serial... In: serial Out: serial Err: serial pcie0.0: Link up Net: eth0: ethernet-controller@72000 Hit any key to stop autoboot: 0 Initializing devices... resetting USB... Bus ehci@50000: USB EHCI 1.00 Bus xhci_pci: Register 400081f NbrPorts 4 Starting the controller USB XHCI 1.00 scanning bus ehci@50000 for devices... 2 USB Device(s) found scanning bus xhci_pci for devices... XHCI timeout on event type 33... cannot recover. BUG at drivers/usb/host/xhci-ring.c:496/xhci_wait_for_event()! BUG! resetting ... U-Boot 2023.04-tld-1 (Jun 11 2023 - 16:24:44 -0700) Pogoplug V4 SoC: Kirkwood 88F6192_A1 Model: Cloud Engines PogoPlug Series 4 DRAM: 128 MiB Core: 20 devices, 16 uclasses, devicetree: separate NAND: 128 MiB MMC: mvsdio@90000: 0 Loading Environment from NAND... OK Resetting console stdin/stdout/stderr to serial... In: serial Out: serial Err: serial pcie0.0: Link up Net: eth0: ethernet-controller@72000 Hit any key to stop autoboot: 0 Initializing devices... resetting USB... Bus ehci@50000: USB EHCI 1.00 Bus xhci_pci: Register 400081f NbrPorts 4 Starting the controller USB XHCI 1.00 scanning bus ehci@50000 for devices... 2 USB Device(s) found scanning bus xhci_pci for devices... XHCI timeout on event type 33... cannot recover. BUG at drivers/usb/host/xhci-ring.c:496/xhci_wait_for_event()! BUG! resetting ... U-Boot 2023.04-tld-1 (Jun 11 2023 - 16:24:44 -0700) Pogoplug V4 SoC: Kirkwood 88F6192_A1 Model: Cloud Engines PogoPlug Series 4 DRAM: 128 MiB Core: 20 devices, 16 uclasses, devicetree: separate NAND: 128 MiB MMC: mvsdio@90000: 0 Loading Environment from NAND... OK Resetting console stdin/stdout/stderr to serial... In: serial Out: serial Err: serial pcie0.0: Link up Net: eth0: ethernet-controller@72000 Hit any key to stop autoboot: 0 Pogo_V4> usb part USB is stopped. Please issue 'usb start' first. Pogo_V4>Removing either the 2.0 or 3.2 allows it to successfully continue on and boot.
If this is how it looks when there's 2 labeled 'rootfs' when it boots, then that makes sense.
I don't see the 2nd test that you've invalidated.
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 23, 2023 11:05PM |
Admin Registered: 13 years ago Posts: 18,900 |
dhargens,
> If this is how it looks when there's 2 labeled
> 'rootfs' when it boots, then that makes sense.
No, the rootfs label is not relevant during u-boot booting. The rootfs label only comes into play when the kernel has booted and looking for the root device.
>
> I don't see the 2nd test that you've invalidated.
It does not matter what file system in on the USB 2.0 drive.
The USB drives initiazation failed in your test with USB 3.0 in the rear port, and USB 2.0 drive in the top port. But apparently it works in my test. So that's what it invalidated, i.e we cannot determine one way or the other the reason why it failed.
You could use wipe the Fit drive and attach it to the top port, and I think it will fail the same way in your test.
======
What capacity are your Ultra and Fit drives?
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> If this is how it looks when there's 2 labeled
> 'rootfs' when it boots, then that makes sense.
No, the rootfs label is not relevant during u-boot booting. The rootfs label only comes into play when the kernel has booted and looking for the root device.
>
> I don't see the 2nd test that you've invalidated.
It does not matter what file system in on the USB 2.0 drive.
The USB drives initiazation failed in your test with USB 3.0 in the rear port, and USB 2.0 drive in the top port. But apparently it works in my test. So that's what it invalidated, i.e we cannot determine one way or the other the reason why it failed.
You could use wipe the Fit drive and attach it to the top port, and I think it will fail the same way in your test.
======
What capacity are your Ultra and Fit drives?
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 23, 2023 11:09PM |
Admin Registered: 13 years ago Posts: 18,900 |
Here is the booting process explanation in the Wiki
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Quote
Developer Section
Jeff's Notes on building uBoot for the Kirwood plugs
Finding address of stock envs of fw_printenv
Basic steps in building Linux modules
Peek/Poke GPIOs in serial console (Armada SoC example)
Peek/Poke GPIOs in serial console (Kirkwood SoC example)
UBIFS example
Booting process in depth discussion: In general, UART booting with kwboot
U-Boot envs location on flash
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 23, 2023 11:20PM |
Registered: 1 year ago Posts: 96 |
Sorry, I should've added this.
When it boots with both drives and errors, I stop it, remove a drive and run 'boot' to continue on, which boots properly.
Prior to boot (during the stop) I ran your example commands and it came up with the following:
Note: power is NOT removed after removing the thumb drive in this test.
On the other hand, the following is from a cold boot (power cycle, a normal boot process), which doesn't allow the error to be seen:
This mirrors your commands for a normal process.
Conclusion: I never get the 2 drives with a rootfs on each to boot simultaneously and work right so I can get these reports.
When there's only 1 rootfs + 1 FAT32 it boots normally, but when 3 drives are present (1 rootfs, 2 FAT32) it won't boot properly until one is removed.
When it boots with both drives and errors, I stop it, remove a drive and run 'boot' to continue on, which boots properly.
Prior to boot (during the stop) I ran your example commands and it came up with the following:
Note: power is NOT removed after removing the thumb drive in this test.
U-Boot 2023.04-tld-1 (Jun 11 2023 - 16:24:44 -0700) Pogoplug V4 SoC: Kirkwood 88F6192_A1 Model: Cloud Engines PogoPlug Series 4 DRAM: 128 MiB Core: 20 devices, 16 uclasses, devicetree: separate NAND: 128 MiB MMC: mvsdio@90000: 0 Loading Environment from NAND... OK Resetting console stdin/stdout/stderr to serial... In: serial Out: serial Err: serial pcie0.0: Link up Net: eth0: ethernet-controller@72000 Hit any key to stop autoboot: 0 Pogo_V4> usb part USB is stopped. Please issue 'usb start' first. Pogo_V4> usb tree USB is stopped. Please issue 'usb start' first. Pogo_V4>If the power should be cycled in this test else it invalidates it, then I understand that and it should be ignored.
On the other hand, the following is from a cold boot (power cycle, a normal boot process), which doesn't allow the error to be seen:
U-Boot 2023.04-tld-1 (Jun 11 2023 - 16:24:44 -0700)
Pogoplug V4
SoC: Kirkwood 88F6192_A1
Model: Cloud Engines PogoPlug Series 4
DRAM: 128 MiB
Core: 20 devices, 16 uclasses, devicetree: separate
NAND: 128 MiB
MMC: mvsdio@90000: 0
Loading Environment from NAND... OK
Resetting console stdin/stdout/stderr to serial...
In: serial
Out: serial
Err: serial
pcie0.0: Link up
Net: eth0: ethernet-controller@72000
Hit any key to stop autoboot: 0
Pogo_V4> usb part
USB is stopped. Please issue 'usb start' first.
Pogo_V4> usb info
USB is stopped. Please issue 'usb start' first.
Pogo_V4> usb reset
resetting USB...
Bus ehci@50000: USB EHCI 1.00
Bus xhci_pci: Register 400081f NbrPorts 4
Starting the controller
USB XHCI 1.00
scanning bus ehci@50000 for devices... 1 USB Device(s) found
scanning bus xhci_pci for devices... 2 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Pogo_V4> usb part
Partition Map for USB device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type
1 2048 120162304 ea5fa0f1-01 83
Pogo_V4> usb info
1: Hub, USB Revision 2.0
- u-boot EHCI Host Controller
- Class: Hub
- PacketSize: 64 Configurations: 1
- Vendor: 0x0000 Product 0x0000 Version 1.0
Configuration: 1
- Interfaces: 1 Self Powered 0mA
Interface: 0
- Alternate Setting 0, Endpoints: 1
- Class Hub
- Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
1: Hub, USB Revision 3.0
- U-Boot XHCI Host Controller
- Class: Hub
- PacketSize: 512 Configurations: 1
- Vendor: 0x0000 Product 0x0000 Version 1.0
Configuration: 1
- Interfaces: 1 Self Powered 0mA
Interface: 0
- Alternate Setting 0, Endpoints: 1
- Class Hub
- Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
2: Mass Storage, USB Revision 3.20
- USB SanDisk 3.2Gen1 0401eab0bfe5exxxxxx
- Class: (from Interface) Mass Storage
- PacketSize: 512 Configurations: 1
- Vendor: 0x0781 Product 0x5583 Version 1.0
Configuration: 1
- Interfaces: 1 Bus Powered 224mA
Interface: 0
- Alternate Setting 0, Endpoints: 2
- Class Mass Storage, Transp. SCSI, Bulk only
- Endpoint 1 In Bulk MaxPacket 1024
- Endpoint 2 Out Bulk MaxPacket 1024
Pogo_V4> usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
u-boot EHCI Host Controller
1 Hub (5 Gb/s, 0mA)
| U-Boot XHCI Host Controller
|
+-2 Mass Storage (5 Gb/s, 224mA)
USB SanDisk 3.2Gen1 0401eab0bfe5exxxxxx
Pogo_V4>
This mirrors your commands for a normal process.
Conclusion: I never get the 2 drives with a rootfs on each to boot simultaneously and work right so I can get these reports.
When there's only 1 rootfs + 1 FAT32 it boots normally, but when 3 drives are present (1 rootfs, 2 FAT32) it won't boot properly until one is removed.
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 23, 2023 11:35PM |
Registered: 1 year ago Posts: 96 |
bodhi Wrote:
-------------------------------------------------------
> It does not matter what file system in on the USB
> 2.0 drive.
>
> The USB drives initiazation failed in your test
> with USB 3.0 in the rear port, and USB 2.0 drive
> in the top port. But apparently it works in my
> test. So that's what it invalidated, i.e we cannot
> determine one way or the other the reason why it
> failed.
>
> You could use wipe the Fit drive and attach it to
> the top port, and I think it will fail the same
> way in your test.
I disagree with your assumption it would error.
I tested this 3.2 Ultra drive (rear, rootfs) with a 2.0 Fit (top, rootfs) and it would not boot. I replaced the the 2.0 top drive with a 2.0 Fit (FAT32) and it booted fine. I can see I missed that test (didn't get them all, I guess), but that's what it did. For fun, I'll test that tomorrow and respond with results.
> What capacity are your Ultra and Fit drives?
It was in an earlier post, but here it is again (it's easy when we were overlapping posts):
16G Fit 2.0 in the top port
64G Ultra "SanDisk 3.2Gen1" in the rear port
-------------------------------------------------------
> It does not matter what file system in on the USB
> 2.0 drive.
>
> The USB drives initiazation failed in your test
> with USB 3.0 in the rear port, and USB 2.0 drive
> in the top port. But apparently it works in my
> test. So that's what it invalidated, i.e we cannot
> determine one way or the other the reason why it
> failed.
>
> You could use wipe the Fit drive and attach it to
> the top port, and I think it will fail the same
> way in your test.
I disagree with your assumption it would error.
I tested this 3.2 Ultra drive (rear, rootfs) with a 2.0 Fit (top, rootfs) and it would not boot. I replaced the the 2.0 top drive with a 2.0 Fit (FAT32) and it booted fine. I can see I missed that test (didn't get them all, I guess), but that's what it did. For fun, I'll test that tomorrow and respond with results.
> What capacity are your Ultra and Fit drives?
It was in an earlier post, but here it is again (it's easy when we were overlapping posts):
16G Fit 2.0 in the top port
64G Ultra "SanDisk 3.2Gen1" in the rear port
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 23, 2023 11:44PM |
Registered: 1 year ago Posts: 96 |
Because I thought it might have something to do with environment vars, I grabbed this:
Pogo_V4> printenv baudrate=115200 bootcmd=run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec; reset bootcmd_exec=if run load_uimage; then; if run load_initrd; then if run load_dtb; then bootm $load_ui bootcmd_uenv=run uenv_load; if test $uenv_loaded -eq 1; then run uenv_import; fi bootdelay=10 bootdev=usb console=ttyS0,115200 device=0:1 devices=usb sata disks=0 1 2 3 dtb_file=/boot/dts/kirkwood-pogoplug_v4.dtb ethaddr=00:25:31:06:22:19 fdtcontroladdr=7b51650 if_netconsole=ping $serverip load_dtb=echo loading DTB $dtb_file ...; load $bootdev $device $load_dtb_addr $dtb_file load_dtb_addr=0x1c00000 load_initrd=echo loading uInitrd ...; load $bootdev $device $load_initrd_addr /boot/uInitrd load_initrd_addr=0x2100000 load_uimage=echo loading uImage ...; load $bootdev $device $load_uimage_addr /boot/uImage load_uimage_addr=0x800000 mtdparts=mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root) preboot_nc=setenv nc_ready 0; for pingstat in 1 2 3; do; sleep 1; if run if_netconsole; then setenvi scan_disk=echo running scan_disk ...; scan_done=0; setenv scan_usb "usb reset; sleep 1; usb reset";e set_bootargs=setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts $custom_s start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin serial,nc; setenv stdout ; stderr=serial stdin=serial stdout=serial uenv_addr=0x810000 uenv_import=echo importing envs ...; env import -t $uenv_addr $filesize uenv_init_devices=echo Initializing devices...; setenv init_usb "usb reset; sleep 1; usb reset"; se; uenv_load=run uenv_init_devices; setenv uenv_loaded 0; for devtype in $devices; do for disknum in $; uenv_read=echo Loading envs from $device_type $disk_number...; if load $device_type $disk_number:1i ver=U-Boot 2023.04-tld-1 (Jun 11 2023 - 16:24:44 -0700)\ Pogoplug V4 Environment size: 2907/131068 bytes Pogo_V4>I installed the updated envs when I updated the uboot, but I'm not using uEnv.txt to load any changes, so I thought that be where we differ.
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 24, 2023 12:45AM |
Admin Registered: 13 years ago Posts: 18,900 |
Quote
When it boots with both drives and errors, I stop it, remove a drive and run 'boot' to continue on, which boots properly.
Prior to boot (during the stop) I ran your example commands and it came up with the following:
Note: power is NOT removed after removing the thumb drive in this test.
U-Boot 2023.04-tld-1 (Jun 11 2023 - 16:24:44 -0700)
Pogoplug V4
SoC: Kirkwood 88F6192_A1
Model: Cloud Engines PogoPlug Series 4
DRAM: 128 MiB
Core: 20 devices, 16 uclasses, devicetree: separate
NAND: 128 MiB
MMC: mvsdio@90000: 0
Loading Environment from NAND... OK
Resetting console stdin/stdout/stderr to serial...
In: serial
Out: serial
Err: serial
pcie0.0: Link up
Net: eth0: ethernet-controller@72000
Hit any key to stop autoboot: 0
Pogo_V4> usb part
USB is stopped. Please issue 'usb start' first.
Pogo_V4> usb tree
USB is stopped. Please issue 'usb start' first.
Pogo_V4>
A "usb start" or "usb reset" command is needed before anything else.
Quote
Conclusion: I never get the 2 drives with a rootfs on each to boot simultaneously and work right so I can get these reports.
When there's only 1 rootfs + 1 FAT32 it boots normally, but when 3 drives are present (1 rootfs, 2 FAT32) it won't boot properly until one is removed.
No, we don't need to see 2 rootfs drives, it would not help and only confuse the issue.
Quote
1 rootfs + 1 FAT32 it boots normally,
That's what we want to see.
Quote
but when 3 drives are present (1 rootfs, 2 FAT32) it won't boot properly until one is removed
It depends if the rootfs is the USB 3.0 drive or 2.0 drive. I would hope that the rootfs is on the USB 3.0 drive attched to the rear port.
However, this 3-drive test is a very good test. Because it surfaced the xhci_pci BUG as you've posted before. This is something I need to investigate further, and fix it in upstream if possible. Unfortunately, one of my Pogo V4 USB 3.0 port got jammed, I need to open the case and reassemble it to get that port usable again.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 24, 2023 04:54PM |
Registered: 1 year ago Posts: 96 |
bodhi Wrote:
-------------------------------------------------------
Yes, the 3.0 Ultra rootfs drive is plugged into the top rear port, with another 3.0 Ultra FAT32 in the bottom port and a 2.0 Fit FAT32 in the top port. It never boots properly until one of the drives is removed.
That's good to hear that I found a useful test to troubleshoot.
I'd originally thought that the two 3.0 drives were of similar type and confusing it (one 64G and the other 32G, but both Cruzer Ultras), but that was disproven by replacing the 2nd Ultra with the BDHD, which still doesn't work and continually cycles. Once one of the drives is removed, it boots properly.
-------------------------------------------------------
Quote
> It depends if the rootfs is the USB 3.0 drive or
> 2.0 drive. I would hope that the rootfs is on the
> USB 3.0 drive attched to the rear port.
Yes, the 3.0 Ultra rootfs drive is plugged into the top rear port, with another 3.0 Ultra FAT32 in the bottom port and a 2.0 Fit FAT32 in the top port. It never boots properly until one of the drives is removed.
Quote
> However, this 3-drive test is a very good test.
> Because it surfaced the xhci_pci BUG as you've
> posted before. This is something I need to
> investigate further, and fix it in upstream if
> possible. Unfortunately, one of my Pogo V4 USB 3.0
> port got jammed, I need to open the case and
> reassemble it to get that port usable again.
That's good to hear that I found a useful test to troubleshoot.
I'd originally thought that the two 3.0 drives were of similar type and confusing it (one 64G and the other 32G, but both Cruzer Ultras), but that was disproven by replacing the 2nd Ultra with the BDHD, which still doesn't work and continually cycles. Once one of the drives is removed, it boots properly.
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 24, 2023 05:57PM |
Admin Registered: 13 years ago Posts: 18,900 |
OK. Here is another wrinkle.
3-drive test.
SanDisk Ultra Fit (3.0) is the rootfs, attaching to one of the rear ports.
SanDisk Cruzer Fit (2.0) is a data drive, attaching to the other rear port.
SanDisk Ultra Backup (2.0) is a data drive, attaching the top port.
Note the usb tree showing the Cruzer Fit is under the XHCI controller, the Ultra Backup is under the EHCI controller. So by this test, both drivers co-exist without problem.
And booted into Debian.
# mount |grep dev | grep sd
===
Edit: typos
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 06/24/2023 08:21PM by bodhi.
3-drive test.
SanDisk Ultra Fit (3.0) is the rootfs, attaching to one of the rear ports.
SanDisk Cruzer Fit (2.0) is a data drive, attaching to the other rear port.
SanDisk Ultra Backup (2.0) is a data drive, attaching the top port.
U-Boot 2023.04-tld-1 (Jun 11 2023 - 16:24:44 -0700)
Pogoplug V4
SoC: Kirkwood 88F6192_A1
Model: Cloud Engines PogoPlug Series 4
DRAM: 128 MiB
Core: 20 devices, 16 uclasses, devicetree: separate
NAND: 128 MiB
MMC: mvsdio@90000: 0
Loading Environment from NAND... OK
Resetting console stdin/stdout/stderr to serial...
In: serial
Out: serial
Err: serial
pcie0.0: Link up
Net: eth0: ethernet-controller@72000
Hit any key to stop autoboot: 0
Pogo_V4> usb start
starting USB...
Bus ehci@50000: USB EHCI 1.00
Bus xhci_pci: Register 400081f NbrPorts 4
Starting the controller
USB XHCI 1.00
scanning bus ehci@50000 for devices... 2 USB Device(s) found
scanning bus xhci_pci for devices... 3 USB Device(s) found
scanning usb for storage devices... 3 Storage Device(s) found
Pogo_V4> usb storage
Device 0: Vendor: SanDisk Rev: 1.01 Prod: Ultra Backup
Type: Removable Hard Disk
Capacity: 61050.6 MB = 59.6 GB (125031680 x 512)
Device 1: Vendor: SanDisk Rev: 1.22 Prod: Cruzer Fit
Type: Removable Hard Disk
Capacity: 7633.5 MB = 7.4 GB (15633408 x 512)
Device 2: Vendor: SanDisk Rev: 1.00 Prod: Ultra Fit
Type: Removable Hard Disk
Capacity: 14663.6 MB = 14.3 GB (30031250 x 512)
Pogo_V4> usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Mass Storage (480 Mb/s, 200mA)
SanDisk Ultra Backup 200431093002Cxxxxxx
1 Hub (5 Gb/s, 0mA)
| U-Boot XHCI Host Controller
|
+-2 Mass Storage (480 Mb/s, 200mA)
| SanDisk Cruzer Fit 4C53200005112xxxxxx
|
+-3 Mass Storage (5 Gb/s, 224mA)
SanDisk Ultra Fit 4C531001560827xxxxxx
Note the usb tree showing the Cruzer Fit is under the XHCI controller, the Ultra Backup is under the EHCI controller. So by this test, both drivers co-exist without problem.
And booted into Debian.
# mount |grep dev | grep sd
/dev/sdc1 on / type ext3 (rw,noatime,errors=remount-ro) /dev/sdb1 on /media/DATA type ext3 (rw,nosuid,nodev,noexec,noatime,errors=remount-ro,user) /dev/sda1 on /media/FATDATA type vfat (rw,nosuid,nodev,noexec,noatime,fmask=0111,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,quiet,utf8,errors=remount-ro,user)# df -h
/dev/sdc1 14G 9.2G 4.1G 70% / /dev/sdb1 7.3G 4.3G 2.7G 62% /media/DATA /dev/sda1 60G 64K 60G 1% /media/FATDATA
===
Edit: typos
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 06/24/2023 08:21PM by bodhi.
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 24, 2023 06:20PM |
Admin Registered: 13 years ago Posts: 18,900 |
So I guess I need to test with a large USB 3.0 HDD drive hoping to see the same bug.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 24, 2023 08:30PM |
Registered: 1 year ago Posts: 96 |
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 June 24, 2023 08:54PM |
Admin Registered: 13 years ago Posts: 18,900 |
> I can’t buy any small drives anymore, so I’m
> loaded with 16G & 32G 2.0 Fits, and 32G Ultras.
> I have 1 64G Ultra I wasn’t aware I’d set up
> for rootfs, which was used in my tests.
That's OK. Small drives setup is proven to work in my test. And you knew what work in your configuration. But it could be good to see you have the similar setup as my test:
- Ultra rootfs in the rear port
- Fit data in the other rear port
- Fit data in the top port.
=====
I can and will try this test 6, too.
=======
I hope I will be able to replicate this bug with a 4TB USB HDD. Once I can do that, I can try to debug the driver.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> loaded with 16G & 32G 2.0 Fits, and 32G Ultras.
> I have 1 64G Ultra I wasn’t aware I’d set up
> for rootfs, which was used in my tests.
That's OK. Small drives setup is proven to work in my test. And you knew what work in your configuration. But it could be good to see you have the similar setup as my test:
- Ultra rootfs in the rear port
- Fit data in the other rear port
- Fit data in the top port.
=====
I can and will try this test 6, too.
Quote
6. Booting with the Cruzer Ultra 3.1 (6.3.8) in a rear port, another Ultra 3.1 in the other rear port (formatted FAT32) and a FAT32 2.0 drive in the top shows constant recycling with "BUG" errors shown above.
=======
I hope I will be able to replicate this bug with a 4TB USB HDD. Once I can do that, I can try to debug the driver.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 July 11, 2023 03:46AM |
Admin Registered: 13 years ago Posts: 18,900 |
A reminder to myself: look at 3 USB drive booting process.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: 2023.04 U-Boot Kirkwood - Pogo V4 July 12, 2023 04:13AM |
Admin Registered: 13 years ago Posts: 18,900 |
dhargens,
> I can’t buy any small drives anymore, so I’m
> loaded with 16G & 32G 2.0 Fits, and 32G Ultras.
> I have 1 64G Ultra I wasn’t aware I’d set up
> for rootfs, which was used in my tests.
Please run this test.
- 64G Ultra or 32G Ultra rootfs attached to one of the rear ports.
- 16G or 32G 2.0 Fit formatted completely (use fdisk to wipe the drive first) as Ext3 data drive attached to the other rear port.
- 16G or 32G 2.0 Fit formatted completely (use fdisk to wipe the drive first) as Ext3 data drive attached to the top port.
Power up, interrupt serial console and,
And post the entire serial console log here.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 07/12/2023 04:45AM by bodhi.
> I can’t buy any small drives anymore, so I’m
> loaded with 16G & 32G 2.0 Fits, and 32G Ultras.
> I have 1 64G Ultra I wasn’t aware I’d set up
> for rootfs, which was used in my tests.
Please run this test.
- 64G Ultra or 32G Ultra rootfs attached to one of the rear ports.
- 16G or 32G 2.0 Fit formatted completely (use fdisk to wipe the drive first) as Ext3 data drive attached to the other rear port.
- 16G or 32G 2.0 Fit formatted completely (use fdisk to wipe the drive first) as Ext3 data drive attached to the top port.
Power up, interrupt serial console and,
usb start usb storage usb tree
And post the entire serial console log here.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 07/12/2023 04:45AM by bodhi.
