bootstd: Scanning for USB bootflow will remove existing SCSI bootflow
Hi Simon,
Here is an observation during testing the bootflow command.
If there is a SCSI bootflow, scanning for USB bootflow will remove that existing SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and it was back to normal. Perhaps there is some kind of indexing problem?
Please see the log below after the break.
All the best, Tony
=============== <BEGIN LOG>
U-Boot 2023.10-rc4-tld-1-00044-g9c21b2a350-dirty (Sep 18 2023 - 12:16:59 -0700) Thecus N2350
<snip>
N2350 > env def -a ## Resetting to default environment
N2350 > bootflow scan scsi pcie0.0: Link down pcie1.0: Link down scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Device 0: (1:0) Vendor: ATA Prod.: ST750LX003-1AC15 Rev: SM12 Type: Hard Disk Capacity: 715404.8 MB = 698.6 GB (1465149168 x 512) ** File not found /boot/boot.bmp **
N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- 0 script ready scsi 1 ahci_scsi.id1lun0.bootdev /boot/boot.scr --- ----------- ------ -------- ---- ------------------------ ---------------- (1 bootflow, 1 valid)
N2350 > bootflow scan usb Bus usb@58000: USB EHCI 1.00 Bus usb3@f0000: MVEBU XHCI INIT controller @ 0xf10f4000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 Bus usb3@f8000: MVEBU XHCI INIT controller @ 0xf10fc000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus usb@58000 for devices... 1 USB Device(s) found scanning bus usb3@f0000 for devices... 1 USB Device(s) found scanning bus usb3@f8000 for devices... 2 USB Device(s) found ** File not found /boot/boot.bmp **
N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- 0 script ready usb_mass_ 1 usb_mass_storage.lun0.boo /boot/boot.scr --- ----------- ------ -------- ---- ------------------------ ---------------- (1 bootflow, 1 valid)
N2350 > bootflow scan scsi ** File not found /boot/boot.bmp ** ** File not found /boot/boot.bmp **
N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- 0 script ready scsi 1 ahci_scsi.id1lun0.bootdev /boot/boot.scr 1 script ready usb_mass_ 1 usb_mass_storage.lun0.boo /boot/boot.scr --- ----------- ------ -------- ---- ------------------------ ---------------- (2 bootflows, 2 valid)
<END LOG>
Hi Tony,
On Mon, 25 Sept 2023 at 14:02, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
Here is an observation during testing the bootflow command.
If there is a SCSI bootflow, scanning for USB bootflow will remove that existing SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and it was back to normal. Perhaps there is some kind of indexing problem?
Yes that's right. The 'botflow scan' command is not additive. The first thing it does is removing existing bootflows.
Please see the log below after the break.
All the best, Tony
===============
<BEGIN LOG>
U-Boot 2023.10-rc4-tld-1-00044-g9c21b2a350-dirty (Sep 18 2023 - 12:16:59 -0700) Thecus N2350
<snip>
N2350 > env def -a ## Resetting to default environment
N2350 > bootflow scan scsi pcie0.0: Link down pcie1.0: Link down scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Device 0: (1:0) Vendor: ATA Prod.: ST750LX003-1AC15 Rev: SM12 Type: Hard Disk Capacity: 715404.8 MB = 698.6 GB (1465149168 x 512) ** File not found /boot/boot.bmp **
N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename
0 script ready scsi 1 ahci_scsi.id1lun0.bootdev /boot/boot.scr
(1 bootflow, 1 valid)
N2350 > bootflow scan usb Bus usb@58000: USB EHCI 1.00 Bus usb3@f0000: MVEBU XHCI INIT controller @ 0xf10f4000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 Bus usb3@f8000: MVEBU XHCI INIT controller @ 0xf10fc000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus usb@58000 for devices... 1 USB Device(s) found scanning bus usb3@f0000 for devices... 1 USB Device(s) found scanning bus usb3@f8000 for devices... 2 USB Device(s) found ** File not found /boot/boot.bmp **
N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename
0 script ready usb_mass_ 1 usb_mass_storage.lun0.boo /boot/boot.scr
(1 bootflow, 1 valid)
N2350 > bootflow scan scsi ** File not found /boot/boot.bmp ** ** File not found /boot/boot.bmp **
N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename
0 script ready scsi 1 ahci_scsi.id1lun0.bootdev /boot/boot.scr 1 script ready usb_mass_ 1 usb_mass_storage.lun0.boo /boot/boot.scr
(2 bootflows, 2 valid)
<END LOG>
Regards, Simon
Hi Simon,
On Tue, Sep 26, 2023 at 4:37 AM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Mon, 25 Sept 2023 at 14:02, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
Here is an observation during testing the bootflow command.
If there is a SCSI bootflow, scanning for USB bootflow will remove that existing SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and it was back to normal. Perhaps there is some kind of indexing problem?
Yes that's right. The 'botflow scan' command is not additive. The first thing it does is removing existing bootflows.
Thanks for clarifying that. I assumed it is additive, because the existing USB bootflow was not removed when I did a "bootflow scan scsi" immediately after (see the end of the log).
Thanks, Tony
Please see the log below after the break.
All the best, Tony
===============
<BEGIN LOG>
U-Boot 2023.10-rc4-tld-1-00044-g9c21b2a350-dirty (Sep 18 2023 - 12:16:59 -0700) Thecus N2350
<snip>
N2350 > env def -a ## Resetting to default environment
N2350 > bootflow scan scsi pcie0.0: Link down pcie1.0: Link down scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Device 0: (1:0) Vendor: ATA Prod.: ST750LX003-1AC15 Rev: SM12 Type: Hard Disk Capacity: 715404.8 MB = 698.6 GB (1465149168 x 512) ** File not found /boot/boot.bmp **
N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename
0 script ready scsi 1 ahci_scsi.id1lun0.bootdev /boot/boot.scr
(1 bootflow, 1 valid)
N2350 > bootflow scan usb Bus usb@58000: USB EHCI 1.00 Bus usb3@f0000: MVEBU XHCI INIT controller @ 0xf10f4000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 Bus usb3@f8000: MVEBU XHCI INIT controller @ 0xf10fc000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus usb@58000 for devices... 1 USB Device(s) found scanning bus usb3@f0000 for devices... 1 USB Device(s) found scanning bus usb3@f8000 for devices... 2 USB Device(s) found ** File not found /boot/boot.bmp **
N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename
0 script ready usb_mass_ 1 usb_mass_storage.lun0.boo /boot/boot.scr
(1 bootflow, 1 valid)
N2350 > bootflow scan scsi ** File not found /boot/boot.bmp ** ** File not found /boot/boot.bmp **
N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename
0 script ready scsi 1 ahci_scsi.id1lun0.bootdev /boot/boot.scr 1 script ready usb_mass_ 1 usb_mass_storage.lun0.boo /boot/boot.scr
(2 bootflows, 2 valid)
<END LOG>
Regards, Simon
Hi Tony,
On Tue, 26 Sept 2023 at 13:40, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Tue, Sep 26, 2023 at 4:37 AM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Mon, 25 Sept 2023 at 14:02, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
Here is an observation during testing the bootflow command.
If there is a SCSI bootflow, scanning for USB bootflow will remove that existing SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and it was back to normal. Perhaps there is some kind of indexing problem?
Yes that's right. The 'botflow scan' command is not additive. The first thing it does is removing existing bootflows.
Thanks for clarifying that. I assumed it is additive, because the existing USB bootflow was not removed when I did a "bootflow scan scsi" immediately after (see the end of the log).
Yes, but I'm not sure what is going on there. Perhaps it is a bug? When you scan SCSI it should not also scan USB.
Regards, SImon
Hi Simon,
On Sun, Oct 1, 2023 at 6:22 PM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Tue, 26 Sept 2023 at 13:40, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Tue, Sep 26, 2023 at 4:37 AM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Mon, 25 Sept 2023 at 14:02, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
Here is an observation during testing the bootflow command.
If there is a SCSI bootflow, scanning for USB bootflow will remove that existing SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and it was back to normal. Perhaps there is some kind of indexing problem?
Yes that's right. The 'botflow scan' command is not additive. The first thing it does is removing existing bootflows.
Thanks for clarifying that. I assumed it is additive, because the existing USB bootflow was not removed when I did a "bootflow scan scsi" immediately after (see the end of the log).
Yes, but I'm not sure what is going on there. Perhaps it is a bug? When you scan SCSI it should not also scan USB.
Yes, it looks like a bug. I think I can see the problem and am working on a patch.
All the best, Tony
Regards, SImon
Hi Simon,
On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Sun, Oct 1, 2023 at 6:22 PM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Tue, 26 Sept 2023 at 13:40, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Tue, Sep 26, 2023 at 4:37 AM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Mon, 25 Sept 2023 at 14:02, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
Here is an observation during testing the bootflow command.
If there is a SCSI bootflow, scanning for USB bootflow will remove that existing SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and it was back to normal. Perhaps there is some kind of indexing problem?
Yes that's right. The 'botflow scan' command is not additive. The first thing it does is removing existing bootflows.
Thanks for clarifying that. I assumed it is additive, because the existing USB bootflow was not removed when I did a "bootflow scan scsi" immediately after (see the end of the log).
Yes, but I'm not sure what is going on there. Perhaps it is a bug? When you scan SCSI it should not also scan USB.
Yes, it looks like a bug. I think I can see the problem and am working on a patch.
Just to let you know, I'm out of time to work on this topic. I will revisit it some other time, if you have not already tracked it down.
All the best, Tony
All the best, Tony
Regards, SImon
Hi Tony,
On Wed, 4 Oct 2023 at 21:23, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Sun, Oct 1, 2023 at 6:22 PM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Tue, 26 Sept 2023 at 13:40, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Tue, Sep 26, 2023 at 4:37 AM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Mon, 25 Sept 2023 at 14:02, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
Here is an observation during testing the bootflow command.
If there is a SCSI bootflow, scanning for USB bootflow will remove that existing SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and it was back to normal. Perhaps there is some kind of indexing problem?
Yes that's right. The 'botflow scan' command is not additive. The first thing it does is removing existing bootflows.
Thanks for clarifying that. I assumed it is additive, because the existing USB bootflow was not removed when I did a "bootflow scan scsi" immediately after (see the end of the log).
Yes, but I'm not sure what is going on there. Perhaps it is a bug? When you scan SCSI it should not also scan USB.
Yes, it looks like a bug. I think I can see the problem and am working on a patch.
Just to let you know, I'm out of time to work on this topic. I will revisit it some other time, if you have not already tracked it down.
If you are able to use 'bootflow scan -l' in each case, then I might be able to see what it is scanning USB, when you are asking for SCSI. I also wonder if this bug may have been fixed due to other changes?
Regards, Simon
Hi Simon,
On Mon, Nov 6, 2023 at 9:25 AM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Wed, 4 Oct 2023 at 21:23, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Sun, Oct 1, 2023 at 6:22 PM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Tue, 26 Sept 2023 at 13:40, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Tue, Sep 26, 2023 at 4:37 AM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Mon, 25 Sept 2023 at 14:02, Tony Dinh mibodhi@gmail.com wrote: > > Hi Simon, > > Here is an observation during testing the bootflow command. > > If there is a SCSI bootflow, scanning for USB bootflow will remove that existing > SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and it was > back to normal. Perhaps there is some kind of indexing problem?
Yes that's right. The 'botflow scan' command is not additive. The first thing it does is removing existing bootflows.
Thanks for clarifying that. I assumed it is additive, because the existing USB bootflow was not removed when I did a "bootflow scan scsi" immediately after (see the end of the log).
Yes, but I'm not sure what is going on there. Perhaps it is a bug? When you scan SCSI it should not also scan USB.
Yes, it looks like a bug. I think I can see the problem and am working on a patch.
Just to let you know, I'm out of time to work on this topic. I will revisit it some other time, if you have not already tracked it down.
If you are able to use 'bootflow scan -l' in each case, then I might be able to see what it is scanning USB, when you are asking for SCSI. I also wonder if this bug may have been fixed due to other changes?
I'm wondering about that, too. I will rerun the test with the master branch with debug trace. If we cannot see it, I'll do it again when other bootstd patches are merged. Right now I am not sure which of your bootstd patches I should apply to the tree for testing, do you have a list for that?
All the best, Tony
Regards, Simon
On Mon, Nov 06, 2023 at 11:42:51AM -0800, Tony Dinh wrote:
Hi Simon,
On Mon, Nov 6, 2023 at 9:25 AM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Wed, 4 Oct 2023 at 21:23, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Sun, Oct 1, 2023 at 6:22 PM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Tue, 26 Sept 2023 at 13:40, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Tue, Sep 26, 2023 at 4:37 AM Simon Glass sjg@chromium.org wrote: > > Hi Tony, > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh mibodhi@gmail.com wrote: > > > > Hi Simon, > > > > Here is an observation during testing the bootflow command. > > > > If there is a SCSI bootflow, scanning for USB bootflow will remove that existing > > SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and it was > > back to normal. Perhaps there is some kind of indexing problem? > > Yes that's right. The 'botflow scan' command is not additive. The > first thing it does is removing existing bootflows.
Thanks for clarifying that. I assumed it is additive, because the existing USB bootflow was not removed when I did a "bootflow scan scsi" immediately after (see the end of the log).
Yes, but I'm not sure what is going on there. Perhaps it is a bug? When you scan SCSI it should not also scan USB.
Yes, it looks like a bug. I think I can see the problem and am working on a patch.
Just to let you know, I'm out of time to work on this topic. I will revisit it some other time, if you have not already tracked it down.
If you are able to use 'bootflow scan -l' in each case, then I might be able to see what it is scanning USB, when you are asking for SCSI. I also wonder if this bug may have been fixed due to other changes?
I'm wondering about that, too. I will rerun the test with the master branch with debug trace. If we cannot see it, I'll do it again when other bootstd patches are merged. Right now I am not sure which of your bootstd patches I should apply to the tree for testing, do you have a list for that?
Right now the only outstanding bootstd patch I know of is your recent one, as I was waiting for Simon's review (which he did today) before merging and applying.
On Mon, Nov 6, 2023 at 11:51 AM Tom Rini trini@konsulko.com wrote:
On Mon, Nov 06, 2023 at 11:42:51AM -0800, Tony Dinh wrote:
Hi Simon,
On Mon, Nov 6, 2023 at 9:25 AM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Wed, 4 Oct 2023 at 21:23, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Sun, Oct 1, 2023 at 6:22 PM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Tue, 26 Sept 2023 at 13:40, Tony Dinh mibodhi@gmail.com wrote: > > Hi Simon, > > On Tue, Sep 26, 2023 at 4:37 AM Simon Glass sjg@chromium.org wrote: > > > > Hi Tony, > > > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh mibodhi@gmail.com wrote: > > > > > > Hi Simon, > > > > > > Here is an observation during testing the bootflow command. > > > > > > If there is a SCSI bootflow, scanning for USB bootflow will remove that existing > > > SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and it was > > > back to normal. Perhaps there is some kind of indexing problem? > > > > Yes that's right. The 'botflow scan' command is not additive. The > > first thing it does is removing existing bootflows. > > Thanks for clarifying that. I assumed it is additive, because the > existing USB bootflow was not removed when I did a "bootflow scan > scsi" immediately after (see the end of the log).
Yes, but I'm not sure what is going on there. Perhaps it is a bug? When you scan SCSI it should not also scan USB.
Yes, it looks like a bug. I think I can see the problem and am working on a patch.
Just to let you know, I'm out of time to work on this topic. I will revisit it some other time, if you have not already tracked it down.
If you are able to use 'bootflow scan -l' in each case, then I might be able to see what it is scanning USB, when you are asking for SCSI. I also wonder if this bug may have been fixed due to other changes?
I'm wondering about that, too. I will rerun the test with the master branch with debug trace. If we cannot see it, I'll do it again when other bootstd patches are merged. Right now I am not sure which of your bootstd patches I should apply to the tree for testing, do you have a list for that?
Right now the only outstanding bootstd patch I know of is your recent one, as I was waiting for Simon's review (which he did today) before merging and applying.
Thanks Tom! I'll run the test in my tree as is then.
All the best, Tony
Hi Simon,
On Mon, Nov 6, 2023 at 12:51 PM Tony Dinh mibodhi@gmail.com wrote:
On Mon, Nov 6, 2023 at 11:51 AM Tom Rini trini@konsulko.com wrote:
On Mon, Nov 06, 2023 at 11:42:51AM -0800, Tony Dinh wrote:
Hi Simon,
On Mon, Nov 6, 2023 at 9:25 AM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Wed, 4 Oct 2023 at 21:23, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Sun, Oct 1, 2023 at 6:22 PM Simon Glass sjg@chromium.org wrote: > > Hi Tony, > > On Tue, 26 Sept 2023 at 13:40, Tony Dinh mibodhi@gmail.com wrote: > > > > Hi Simon, > > > > On Tue, Sep 26, 2023 at 4:37 AM Simon Glass sjg@chromium.org wrote: > > > > > > Hi Tony, > > > > > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh mibodhi@gmail.com wrote: > > > > > > > > Hi Simon, > > > > > > > > Here is an observation during testing the bootflow command. > > > > > > > > If there is a SCSI bootflow, scanning for USB bootflow will remove that existing > > > > SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and it was > > > > back to normal. Perhaps there is some kind of indexing problem? > > > > > > Yes that's right. The 'botflow scan' command is not additive. The > > > first thing it does is removing existing bootflows. > > > > Thanks for clarifying that. I assumed it is additive, because the > > existing USB bootflow was not removed when I did a "bootflow scan > > scsi" immediately after (see the end of the log). > > Yes, but I'm not sure what is going on there. Perhaps it is a bug? > When you scan SCSI it should not also scan USB.
Yes, it looks like a bug. I think I can see the problem and am working on a patch.
Just to let you know, I'm out of time to work on this topic. I will revisit it some other time, if you have not already tracked it down.
If you are able to use 'bootflow scan -l' in each case, then I might be able to see what it is scanning USB, when you are asking for SCSI. I also wonder if this bug may have been fixed due to other changes?
I'm wondering about that, too. I will rerun the test with the master branch with debug trace. If we cannot see it, I'll do it again when other bootstd patches are merged. Right now I am not sure which of your bootstd patches I should apply to the tree for testing, do you have a list for that?
Right now the only outstanding bootstd patch I know of is your recent one, as I was waiting for Simon's review (which he did today) before merging and applying.
Thanks Tom! I'll run the test in my tree as is then.
The good news: apparently one of your recent bootstd patches has fixed this problem! I think your bootstd mmc scanning patch is probably where it was fixed.
I tested with rc2 plus my recent patch (not yet merged to master) in the tree: https://patchwork.ozlabs.org/project/uboot/patch/20231102185116.21708-1-mibo...
For future reference, I've included the log here after the break.
All the best, Tony
================ <BEGIN LOG>
U-Boot 2024.01-rc2-tld-1-00002-g148117d278 (Nov 06 2023 - 13:36:33 -0800) Thecus N2350
SoC: MV88F6820-A0 at 1066 MHz DRAM: 1 GiB (533 MHz, 32-bit, ECC not enabled) Core: 65 devices, 23 uclasses, devicetree: separate NAND: 512 MiB MMC: Loading Environment from SPIFlash... SF: Detected mx25l3205d with page size 256 Bytes, erase size 4 KiB, total 4 MiB *** Warning - bad CRC, using default environment
Model: Thecus N2350 Net: Warning: ethernet@70000 (eth0) using random MAC address - 2e:49:f0:ba:d8:b8 eth0: ethernet@70000 Hit any key to stop autoboot: 0 N2350 > setenv def -a N2350 > bootdev l Seq Probed Status Uclass Name --- ------ ------ -------- ------------------ 0 [ ] OK ethernet ethernet@70000.bootdev --- ------ ------ -------- ------------------ (1 bootdev)
N2350 > bootflow scan usb Bus usb@58000: USB EHCI 1.00 Bus usb3@f0000: MVEBU XHCI INIT controller @ 0xf10f4000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 Bus usb3@f8000: MVEBU XHCI INIT controller @ 0xf10fc000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus usb@58000 for devices... 1 USB Device(s) found scanning bus usb3@f0000 for devices... 1 USB Device(s) found scanning bus usb3@f8000 for devices... 2 USB Device(s) found ** File not found /boot/boot.bmp **
N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- 0 script ready usb_mass_ 1 usb_mass_storage.lun0.boo /boot/boot.scr --- ----------- ------ -------- ---- ------------------------ ---------------- (1 bootflow, 1 valid)
N2350 > bootflow scan scsi pcie0.0: Link down pcie1.0: Link down scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Device 0: (1:0) Vendor: ATA Prod.: ST750LX003-1AC15 Rev: SM12 Type: Hard Disk Capacity: 715404.8 MB = 698.6 GB (1465149168 x 512) ** File not found /boot/boot.bmp **
N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- 0 script ready scsi 1 ahci_scsi.id1lun0.bootdev /boot/boot.scr --- ----------- ------ -------- ---- ------------------------ ---------------- (1 bootflow, 1 valid)
N2350 > bootflow scan usb ** File not found /boot/boot.bmp ** N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- 0 script ready usb_mass_ 1 usb_mass_storage.lun0.boo /boot/boot.scr --- ----------- ------ -------- ---- ------------------------ ---------------- (1 bootflow, 1 valid)
N2350 > bootflow scan scsi ** File not found /boot/boot.bmp ** N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- 0 script ready scsi 1 ahci_scsi.id1lun0.bootdev /boot/boot.scr --- ----------- ------ -------- ---- ------------------------ ---------------- (1 bootflow, 1 valid) N2350 > N2350 > bootflow scan usb ** File not found /boot/boot.bmp ** N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- 0 script ready usb_mass_ 1 usb_mass_storage.lun0.boo /boot/boot.scr --- ----------- ------ -------- ---- ------------------------ ---------------- (1 bootflow, 1 valid)
<END LOG>
Hi Tony,
On Mon, 6 Nov 2023 at 23:41, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Mon, Nov 6, 2023 at 12:51 PM Tony Dinh mibodhi@gmail.com wrote:
On Mon, Nov 6, 2023 at 11:51 AM Tom Rini trini@konsulko.com wrote:
On Mon, Nov 06, 2023 at 11:42:51AM -0800, Tony Dinh wrote:
Hi Simon,
On Mon, Nov 6, 2023 at 9:25 AM Simon Glass sjg@chromium.org wrote:
Hi Tony,
On Wed, 4 Oct 2023 at 21:23, Tony Dinh mibodhi@gmail.com wrote:
Hi Simon,
On Mon, Oct 2, 2023 at 12:25 PM Tony Dinh mibodhi@gmail.com wrote: > > Hi Simon, > > On Sun, Oct 1, 2023 at 6:22 PM Simon Glass sjg@chromium.org wrote: > > > > Hi Tony, > > > > On Tue, 26 Sept 2023 at 13:40, Tony Dinh mibodhi@gmail.com wrote: > > > > > > Hi Simon, > > > > > > On Tue, Sep 26, 2023 at 4:37 AM Simon Glass sjg@chromium.org wrote: > > > > > > > > Hi Tony, > > > > > > > > On Mon, 25 Sept 2023 at 14:02, Tony Dinh mibodhi@gmail.com wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > Here is an observation during testing the bootflow command. > > > > > > > > > > If there is a SCSI bootflow, scanning for USB bootflow will remove that existing > > > > > SCSI bootflow. To bring it back, I scanned for SCSI bootflow again, and it was > > > > > back to normal. Perhaps there is some kind of indexing problem? > > > > > > > > Yes that's right. The 'botflow scan' command is not additive. The > > > > first thing it does is removing existing bootflows. > > > > > > Thanks for clarifying that. I assumed it is additive, because the > > > existing USB bootflow was not removed when I did a "bootflow scan > > > scsi" immediately after (see the end of the log). > > > > Yes, but I'm not sure what is going on there. Perhaps it is a bug? > > When you scan SCSI it should not also scan USB. > > Yes, it looks like a bug. I think I can see the problem and am working > on a patch.
Just to let you know, I'm out of time to work on this topic. I will revisit it some other time, if you have not already tracked it down.
If you are able to use 'bootflow scan -l' in each case, then I might be able to see what it is scanning USB, when you are asking for SCSI. I also wonder if this bug may have been fixed due to other changes?
I'm wondering about that, too. I will rerun the test with the master branch with debug trace. If we cannot see it, I'll do it again when other bootstd patches are merged. Right now I am not sure which of your bootstd patches I should apply to the tree for testing, do you have a list for that?
Right now the only outstanding bootstd patch I know of is your recent one, as I was waiting for Simon's review (which he did today) before merging and applying.
Thanks Tom! I'll run the test in my tree as is then.
The good news: apparently one of your recent bootstd patches has fixed this problem! I think your bootstd mmc scanning patch is probably where it was fixed.
I tested with rc2 plus my recent patch (not yet merged to master) in the tree: https://patchwork.ozlabs.org/project/uboot/patch/20231102185116.21708-1-mibo...
For future reference, I've included the log here after the break.
All the best, Tony
================
<BEGIN LOG>
U-Boot 2024.01-rc2-tld-1-00002-g148117d278 (Nov 06 2023 - 13:36:33 -0800) Thecus N2350
SoC: MV88F6820-A0 at 1066 MHz DRAM: 1 GiB (533 MHz, 32-bit, ECC not enabled) Core: 65 devices, 23 uclasses, devicetree: separate NAND: 512 MiB MMC: Loading Environment from SPIFlash... SF: Detected mx25l3205d with page size 256 Bytes, erase size 4 KiB, total 4 MiB *** Warning - bad CRC, using default environment
Model: Thecus N2350 Net: Warning: ethernet@70000 (eth0) using random MAC address - 2e:49:f0:ba:d8:b8 eth0: ethernet@70000 Hit any key to stop autoboot: 0 N2350 > setenv def -a N2350 > bootdev l Seq Probed Status Uclass Name
0 [ ] OK ethernet ethernet@70000.bootdev
(1 bootdev)
N2350 > bootflow scan usb Bus usb@58000: USB EHCI 1.00 Bus usb3@f0000: MVEBU XHCI INIT controller @ 0xf10f4000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 Bus usb3@f8000: MVEBU XHCI INIT controller @ 0xf10fc000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus usb@58000 for devices... 1 USB Device(s) found scanning bus usb3@f0000 for devices... 1 USB Device(s) found scanning bus usb3@f8000 for devices... 2 USB Device(s) found ** File not found /boot/boot.bmp **
N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename
0 script ready usb_mass_ 1 usb_mass_storage.lun0.boo /boot/boot.scr
(1 bootflow, 1 valid)
N2350 > bootflow scan scsi pcie0.0: Link down pcie1.0: Link down scanning bus for devices... SATA link 0 timeout. Target spinup took 0 ms. AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Device 0: (1:0) Vendor: ATA Prod.: ST750LX003-1AC15 Rev: SM12 Type: Hard Disk Capacity: 715404.8 MB = 698.6 GB (1465149168 x 512) ** File not found /boot/boot.bmp **
N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename
0 script ready scsi 1 ahci_scsi.id1lun0.bootdev /boot/boot.scr
(1 bootflow, 1 valid)
N2350 > bootflow scan usb ** File not found /boot/boot.bmp ** N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename
0 script ready usb_mass_ 1 usb_mass_storage.lun0.boo /boot/boot.scr
(1 bootflow, 1 valid)
N2350 > bootflow scan scsi ** File not found /boot/boot.bmp ** N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename
0 script ready scsi 1 ahci_scsi.id1lun0.bootdev /boot/boot.scr
(1 bootflow, 1 valid) N2350 > N2350 > bootflow scan usb ** File not found /boot/boot.bmp ** N2350 > bootflow l Showing all bootflows Seq Method State Uclass Part Name Filename
0 script ready usb_mass_ 1 usb_mass_storage.lun0.boo /boot/boot.scr
(1 bootflow, 1 valid)
<END LOG>
That's great! Thank you for testing and for the log.
Regards, Simon
participants (3)
-
Simon Glass -
Tom Rini -
Tony Dinh