Jump to content

Odroid N2 Kernel>4.9 = No boot on USB SATA SSD


Doopie

Recommended Posts

Hi i've tried everything now and really out of options and almost out of hair.....

Hardware:
32GB or 256GB Samsung EVO Plus Sd-Card
500GB Samsung USB SATA SSD (MU-PA500B)
Odroid N2 with the latest petit boot

All images with kernel 4.9 will boot straight of the SSD without a problem or much work.

But when i try images anything above 4.9 it won't boot , whatever i do:

What have i tried with the images with kernel 5.4X

1) Image straight to SSD Black screen nothing happens ( SPI or MMC mode makes no difference)
2) Image on Sd-card, boot into Armbian and use :sudo armbian-config
    * System --> Install - installs to SATA, eMMC, NAND or USB --> Boot from SD : System on SATA or USB.--> wait for about 8 minutes and reboot. Dead...black screen
3) Flash image with 4.9X kernel directly on SSD, boot into Armbian. Use : sudo armbian-config and change kernel there and reboot. Dead...black screen

Flipping the switches from SPI to MMC and back doesn't help.

 

 

Link to comment
Share on other sites

On 3/31/2020 at 3:48 PM, Doopie said:
 

Hi i've tried everything now and really out of options and almost out of hair.....

 

 

I might face the same troubles like you, described here FYI:

 

I'm using Armbian_20.02.3_Odroidn2_bionic_current_5.4.21_minimal.img

 

Two updates on top of that thread:

 

- I'm waiting for the serial cable, found a merchant with quicker delivery -> that shall help better understand what is going on under the hood

- I tested with a USB flash drive and managed to move my system from SD to there. That worked without any glitch. Therefore I suppose there is a real problem with the USB/SATA handling itself...

 

Link to comment
Share on other sites

Same for me. I tried to move my data to a Usb-SSD but got basically the same result. Black screen and no boot. Im on latest upgrade too:

root@OdroidN2:/# uname -a
Linux OdroidN2 5.4.28-meson64 #20.02.8 SMP PREEMPT Mon Mar 30 09:12:52 CEST 2020 aarch64 aarch64 aarch64 GNU/Linux

 

Link to comment
Share on other sites

I have found depending on the monitor being used SPI will not find it when leaving program. Once the blue led heartbeat is flashing turn your monitor/tv off, wait a sec or two and turn it back on. This works for me even with Retro Arena and an old plasma tv installed on a usb ssd. I run 2 card readers and 2 usb ssd"s plugged in and can boot any of them from SPI.

Link to comment
Share on other sites

On 3/31/2020 at 3:48 PM, Doopie said:

...

 

Finally I made this work with Armbian_20.02.5_Odroidn2_buster_legacy_4.9.216, basically can confirm your experience.

 

What is still strange, how come the 5.x kernel works like a charm with a UFD stick, and fails to recognize the USB-SATA disk...

 

Are you aware of any bug being tracking for this one?

Link to comment
Share on other sites

I'm getting out of ideas how to make more visibility for this. I reported here and other armbian forums, reddit, etc. but honestly not much has happened.

 

While I'm fine for now with the legacy kernel, that won't last forever.

 

How do you guys cope with this issue, until the linux devs (?) take care of it? If they will ever...

Link to comment
Share on other sites

Still doesn't work for me (focal mainline kernel 5.6.y) - I can start on sdd, change hostname, make it a static ip, reboot - works fine. As soon as I try to nand-sata-install and boot from sdd + system on usb it just disappears after the reboot. Pity, works fine with the legacy.

Link to comment
Share on other sites

On 6/16/2020 at 6:40 PM, nicko said:

system on usb it just disappears after the reboot. Pity, works fine with the legacy.


Could be related to this general problem (should be fixed with recent  20.05.4 images)

 

Link to comment
Share on other sites

12 hours ago, Igor said:


Could be related to this general problem (should be fixed with recent  20.05.4 images)

 

 

I'm afraid not. :(

 

Just tried, my observations below:

 

Welcome to Armbian Focal with Linux 5.6.18-meson64

Linux odroidn2 5.6.18-meson64 #20.05.4 SMP PREEMPT Mon Jun 15 01:50:20 CEST 2020 aarch64 aarch64 aarch64 GNU/Linux

 

I had high hopes with kernel 5.6, but no luck, this is still not working, therefore need to revert to 4.9.x...

 

Right now I have 3 USB devices connected to my N2:

 

1. Sandisk UFD: idVendor=0781, idProduct=5583

2. Seagate USB to SATA enclosure (ASM1053):  idVendor=0bc2, idProduct=2322

3. JMS578 USB to SATA enclosure: idVendor=152d, idProduct=0578

 

What do I see after a "reboot" command in dmesg?

 

1. Sandisk is just fine, recognized:

[    3.487194] usb 2-1.4: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[    3.506316] usb 2-1.4: New USB device found, idVendor=0781, idProduct=5583, bcdDevice= 1.00
[    3.506320] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.506323] usb 2-1.4: Product: Ultra Fit
[    3.506326] usb 2-1.4: Manufacturer: SanDisk

 

and attached as sda:

 

[    4.514269] scsi 0:0:0:0: Direct-Access     SanDisk  Ultra Fit        1.00 PQ: 0 ANSI: 6
[    4.514879] sd 0:0:0:0: [sda] 120176640 512-byte logical blocks: (61.5 GB/57.3 GiB)
[    4.515917] sd 0:0:0:0: [sda] Write Protect is off
[    4.515921] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
[    4.516227] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    4.547637]  sda: sda1
[    4.549671] sd 0:0:0:0: [sda] Attached SCSI removable disk

 

2. Seagate was recognized:

 

[    3.729400] usb 2-1.1: new SuperSpeed Gen 1 USB device number 4 using xhci-hcd
[    3.750186] usb 2-1.1: New USB device found, idVendor=0bc2, idProduct=2322, bcdDevice= 0.00
[    3.750191] usb 2-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[    3.750194] usb 2-1.1: Product: Expansion
[    3.750197] usb 2-1.1: Manufacturer: Seagate

 

but attached as sdb much later:

 

[   33.758648] USB_PWR_EN: disabling
[   35.818446] sd 1:0:0:0: tag#17 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
[   35.818466] sd 1:0:0:0: tag#17 CDB: opcode=0x9e, sa=0x10 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00
[   35.834439] scsi host1: uas_eh_device_reset_handler start
[   35.914806] usb 2-1.1: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd
[   35.936879] scsi host1: uas_eh_device_reset_handler success
[   35.942879] sd 1:0:0:0: [sdb] 976773167 512-byte logical blocks: (500 GB/466 GiB)
[   36.283252] sd 1:0:0:0: [sdb] Write Protect is off
[   36.283256] sd 1:0:0:0: [sdb] Mode Sense: 4f 00 00 00
[   36.283478] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   36.283748] sd 1:0:0:0: [sdb] Optimal transfer size 33553920 bytes
[   36.328292] Alternate GPT is invalid, using primary GPT.
[   36.328306]  sdb: sdb1
[   36.329552] sd 1:0:0:0: [sdb] Attached SCSI disk

 

BTW what is USB_PWR_EN, are we looking at something interesting here?

 

3. Oh, yeah, and the JMS enclosure. That did not even power up after reboot, that's clearly obvious as the enclosure's LED wasn't up at all.

 

After reconnecting manually to the USB port:

 

[ 1202.061262] usb 2-1.2: new SuperSpeed Gen 1 USB device number 5 using xhci-hcd
[ 1202.082455] usb 2-1.2: New USB device found, idVendor=152d, idProduct=0578, bcdDevice=31.02
[ 1202.082467] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1202.082475] usb 2-1.2: Product: USB to ATA/ATAPI Bridge
[ 1202.082483] usb 2-1.2: Manufacturer: JMicron
[ 1202.082491] usb 2-1.2: SerialNumber: 0123456789ABCDEF
[ 1202.094431] scsi host2: uas
[ 1202.095965] scsi 2:0:0:0: Direct-Access     JMicron  Generic          3102 PQ: 0 ANSI: 6
[ 1202.097561] sd 2:0:0:0: Attached scsi generic sg2 type 0

But actually being mounted as sdc needed another 30 seconds:

 

[ 1233.991198]  sdc: sdc1
[ 1233.995322] sd 2:0:0:0: [sdc] Attached SCSI disk

 

--

 

What I see here: all the above just works with the 4.9.x kernels.

 

My gut feeling is that this has to do something with USB power cycling (or the lack of it) during startup. Some other forums suggested to check on UAS and disable it via quirks, but this is clearly not an UAS problem, and both kernels (4.x and 5.x) have the UAS module loaded (checked with modprobe uas).

 

@Igor do you have any idea how to proceed from here?

 


EDIT: this is how the boot process looks like with 4.9, the JMS and my SSD is immediately recognized, no 30 seconds delays, etc. Actually I'm booting off the SD and then the system is already on the SSD (have moved there with  nand-sata-install):


[    5.397633] usb 2-1.1: New USB device found, idVendor=152d, idProduct=0578
[    5.397636] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    5.397639] usb 2-1.1: Product: USB to ATA/ATAPI Bridge
[    5.397641] usb 2-1.1: Manufacturer: JMicron
[    5.397643] usb 2-1.1: SerialNumber: 0123456789ABCDEF
[    5.407569] scsi host0: uas
[    5.410712] scsi 0:0:0:0: Direct-Access     JMicron  Generic          3102 PQ: 0 ANSI: 6
[    5.454904] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    5.952266] sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/233 GiB)
[    5.952270] sd 0:0:0:0: [sda] 4096-byte physical blocks
[    5.953160] sd 0:0:0:0: [sda] Write Protect is off
[    5.953165] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
[    5.953512] sd 0:0:0:0: [sda] Disabling FUA
[    5.953516] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    5.953659] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring
[    5.953663] xhci-hcd xhci-hcd.0.auto: @00000000cf612c60 00000000 00000000 1b000000 04078001
[    5.953848] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
[    5.956601]  sda: sda1
[    5.961031] sd 0:0:0:0: [sda] Attached SCSI disk
[    6.739699] EXT4-fs (sda1): mounted filesystem with writeback data mode. Opts: data=writeback

 

 

 

 

Edited by vzoltan
Adding 4.9 boot dmesg
Link to comment
Share on other sites

I've had some success with this which I posted elsewhere:

 

 

It's not perfect, in particular you need to be mindful of Armbian updates which sometimes break things again. My system is up to kernel 5.8.14 on the hard drive now and that's OK, 5.8.15 seemed to break things so I had to rollback. I've decided to leave it on 5.8.14 for the time being,

Link to comment
Share on other sites

Am 2.4.2020 um 09:50 schrieb balbes150:

Piteboot does not have the correct system startup priority. If you install a modified version of uboot-SPI in SPI, you can start the system directly from USB (the polling order will be USB - > SD - > eMMC - > piteboot).

Hallo @balbes150,

 

which SPI Version should we use?

 

Regards

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines