USB not working after kernel upgrade (NSA320)

Hey there!

I have no idea what kernel version broke this, but in my old vmlinuz-3.12.0-kirkwood-tld-5 USB was working well but it doesn't work in 4.5 nor 4.8.3. The issue with it is that it won't detect the devices I plug in. No trace on dmesg nor lsusb.
Since I havent updated my rootfs I was wondering whether the usb device discovering depends on some service I do not have installed in my machine.
In all the kernels the boot messages regarding to USB seem the same, the driver orion-ehci is lodaded and the root hub is discovered, so there's nothing worth mentioning to be fair.

Thanks!

davidgf,

There is no extra service needed for USB. Have you tried a different USB drive?

You might want to post dmesg output here anyway, just in case something was wrong and you've overlooked.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Sure!

I tried with several devices, all working in the old kernel. In the new kernel I got this:

http://pastebin.com/EHZGTz2L

In the old one (the modem was plugged):

http://pastebin.com/gFPz4W5H

I'd like to repeat again that I'm using the same rootfs, and it's old, I recall it's the one it came with kernel 3, I installed this at least 3 years ago following your posts here. Great work BTW! I like that you always keep github repos for the stuff so people can build themselves.

Thanks!

davidgf,

Bus 001 Device 006: ID 12d1:1001 Huawei Technologies Co., Ltd. E169/E620/E800 HSDPA Modem

I see that this is not a USB storage drive! That's definitely a different category. I'll look into the possibility of this modem driver is missing in the new kernel.

If you plug in a normal USB storage drive, does kernel 4.8.3 detected it OK?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

In this particular case I was plugging a modem. But same result with a pendrive.
Summarizing: with kernel 4.8.3 (and 4.5) when I plug a usb device no changes in lsusb, dmesg remains absolutely silent!!

davidgf Wrote:
-------------------------------------------------------
> In this particular case I was plugging a modem.
> But same result with a pendrive.
> Summarizing: with kernel 4.8.3 (and 4.5) when I
> plug a usb device no changes in lsusb, dmesg
> remains absolutely silent!!

That's strange! no other Kirkwood boxes shows this problem. USB driver is the same for all.

Anybody has the NSA320 box, please confirm if you see the same problem with USB as davidgf described.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

It is strange indeed. I cant come up with a way of debugging it, since not even the usb driver seems to be notified about the existance of the device. My gut tells me there is some issue with the event (or irq) that presents the new device.

davidgf Wrote:
-------------------------------------------------------
> It is strange indeed. I cant come up with a way of
> debugging it, since not even the usb driver seems
> to be notified about the existance of the device.
> My gut tells me there is some issue with the event
> (or irq) that presents the new device.

It behaves as though there is no power in the port. Let's wait a few to see if anybody else has this problem.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Do you have a quick way to download every kernel you've ever released? I was just thinking on maybe running a regression test to identify what kernel breaks it.
I have the suspicion no one will have such a problem, otherwise they would have complained about it already.

BTW, I'm using nsa320.dtb, is that the correct one? Cause there's an nsa320s.dtb as well.
It just occured me that the old kernel where USB works might be a non FDT kernel and that might be the difference.
Thanks!

Edit: Nevermind I just realized NSA320S is another product :D



Edited 1 time(s). Last edit at 11/20/2016 06:09AM by davidgf.

davidgf Wrote:
-------------------------------------------------------
> BTW, I'm using nsa320.dtb, is that the correct
> one? Cause there's an nsa320s.dtb as well.
> It just occured me that the old kernel where USB
> works might be a non FDT kernel and that might be
> the difference.
> Thanks!
>
> Edit: Nevermind I just realized NSA320S is another
> product :D

Which u-boot is installed in this box? is it stock or a newer u-boot?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I dont recall upgrading it but I guess I did, since the SoC is unbrickable I probably flashed it. I'll check later. Is it possible to check from Linux? Otherwise I will use the network uboot console.

This is what I have:

U-Boot 2011.12 (May 03 2012 - 17:04:23)
ZyXEL NSA320 2-Bay Power Media Server
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q3-67) 4.4.1
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709

davidgf Wrote:
-------------------------------------------------------
> This is what I have:
>
> U-Boot 2011.12 (May 03 2012 - 17:04:23)
> ZyXEL NSA320 2-Bay Power Media Server
> arm-none-linux-gnueabi-gcc (Sourcery G++ Lite
> 2009q3-67) 4.4.1
> GNU ld (Sourcery G++ Lite 2009q3-67)
> 2.19.51.20090709

Ah, you are running this pretty old u-boot. And it must not have USB power turned on proprely. Back in those days, the NSA320 USB power was turn on by a u-boot memory poke, or baked into the kernel. You were running kernel 3.12.x, so that kernel patch must have that poke to make it work. It's been too long I can't remember adding that into kernel 3.12 :) . This is a non-FDT kernel, so it is in the setup code.

So the mystery solved! no need to track it down. Now you should either :

- update u-boot to 2016.05: http://forum.doozan.com/read.php?3,12381
or
- Find that memory poke somewhere in the forum and add an u-boot env to trigger it during boot.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Ok great!
BTW this "flash_erase /dev/mtd0 0 4" gives me permission denied!
Is the MTD flash protected in any way?

Oh and not just that, my flash partitions look like this:

dev: size erasesize name
mtd0: 00100000 00020000 "uboot"
mtd1: 00080000 00020000 "uboot_env"
mtd2: 00080000 00020000 "key_store"
mtd3: 00080000 00020000 "info"
mtd4: 00a00000 00020000 "etc"
mtd5: 00a00000 00020000 "kernel_1"
mtd6: 02fc0000 00020000 "rootfs1"
mtd7: 00a00000 00020000 "kernel_2"
mtd8: 02fc0000 00020000 "rootfs2"

with a 1MB uboot part, while the uboot fw (uboot.2016.05-tld-1.nsa320.mtd0.kwb) is only 512kB. Is it too old to perform an straightforward update ? Thanks!

davidgf Wrote:
-------------------------------------------------------
> Oh and not just that, my flash partitions look
> like this:
>
> dev: size erasesize name
> mtd0: 00100000 00020000 "uboot"
> mtd1: 00080000 00020000 "uboot_env"
> mtd2: 00080000 00020000 "key_store"
> mtd3: 00080000 00020000 "info"
> mtd4: 00a00000 00020000 "etc"
> mtd5: 00a00000 00020000 "kernel_1"
> mtd6: 02fc0000 00020000 "rootfs1"
> mtd7: 00a00000 00020000 "kernel_2"
> mtd8: 02fc0000 00020000 "rootfs2"
>
> with a 1MB uboot part, while the uboot fw
> (uboot.2016.05-tld-1.nsa320.mtd0.kwb) is only
> 512kB. Is it too old to perform an straightforward
> update ? Thanks!

Your mtdparts look fine. This is the stock definition that I kept intact in the new u-boot. And flashing will be correct in that only 4 blocks are used for u-boot.

Please get the listing of :

fw_printenv

I think your u-boot bootargs env must have mtd0 specified as read-only.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Side question: why do we even have partitions in NAND? 99.9% people here load the kernel from USB/SATA, what's the point? Thanks!

arcNumber=3956
baudrate=115200
bootcmd=run boot_sata1; run boot_sata2; run bootcmd_usb; usb stop; run bootcmd_rescue; reset
bootcmd_usb=run usb_init; run usb_load_uimage; run set_bootargs_usb; run usb_boot;
bootdelay=3
console=ttyS0,115200
ethact=egiga0
ethaddr=c8:6c:87:12:34:56
if_netconsole=ping $serverip
ipaddr=192.168.11.150
mainlineLinux=yes
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),512K(uboot_env),512K(key_store),512K(info),10M(etc),10M(kernel_1),48896K(rootfs1),10M(kernel_2),-(rootfs2)
netmask=255.255.255.0
partition=nand0,2
preboot=run if_netconsole start_netconsole
serverip=192.168.11.149
set_bootargs_usb=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
stderr=serial
stdin=serial
stdout=serial
usb_boot=if ext2load usb $usb_device 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000;else bootm 0x800000;fi;
usb_device=0:1
usb_init=usb start
usb_load_uimage=mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage
usb_root=LABEL=USBROOT
usb_rootdelay=10
usb_rootfstype=ext2
boot_sata1=mw 0x800000 0 1; setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootdelay=10 ; ide reset; ext2load ide 0:1 0x800000 /boot/uImage; ext2load ide 0:1 0x01100000 /boot/uInitrd; bootm 0x00800000 0x01100000
boot_sata2=mw 0x800000 0 1; setenv bootargs console=ttyS0,115200 root=/dev/sdb1 rootdelay=10 ; ide reset; ext2load ide 1:1 0x800000 /boot/uImage; ext2load ide 1:1 0x01100000 /boot/uInitrd; bootm 0x00800000 0x01100000

davidgf,

> Side question: why do we even have partitions in
> NAND? 99.9% people here load the kernel from
> USB/SATA, what's the point? Thanks!

Stock u-boot, kernel and rootfs are in NAND partitions. Even though we are going to boot with USB or SATA, everything except u-boot are kept intact, so that you will have a restore path. Should you want to sell the box, for example, you could restore old u-boot and done. Or these partitions can be used later for other things such as a rescue system (which might requires the partitions to be redefined to a different layout).

1. You have not done anything yet, so you can set the bootargs and reboot. Your SATA booting envs does not have bootargs.

I assume you have only 1 HDD in your box, so it is always sda1. And you are running kernel 4.8.3 on this HDD.

fw_setenv set_bootargs_sata 'setenv bootargs console=$console root=/dev/sda1 rootdelay=10 $mtdparts'
fw_setenv bootcmd 'run set_bootargs_sata; run boot_sata1; run boot_sata2; run bootcmd_usb; usb stop; run bootcmd_rescue; reset'

After you've booted into Debian, do the u-boot installation again.

2. Alternatively, I've noticed that you have USB booting already setup. You could boot with USB and flash u-boot without changing u-boot envs as described in number 1 above.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hey thanks!
Is it just me or that doesn't make any sense at all? You are setting bootargs and boot_sata1 will overwrite them... :D
Let's go one step back: what is the thing that prevents linux from overwriting the flash? Is it a kernel protection, is it a fw protection?

Thanks again!

davidgf Wrote:
-------------------------------------------------------
> Hey thanks!
> Is it just me or that doesn't make any sense at
> all? You are setting bootargs and boot_sata1 will
> overwrite them... :D
> Let's go one step back: what is the thing that
> prevents linux from overwriting the flash? Is it a
> kernel protection, is it a fw protection?
>
> Thanks again!

Ah :) I see I overlooked that. Take out your set botargs in the boot_sata1 and it will work.

Basically, boot_sata1 does not have mtdparts that's why your mtd0 was read only.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Is the new uboot using the ENV partition?
Meaning, if I update the bootloader, will I loose all my env?
I imagine the new uboot stores env at the end of the first partition, since its 512kb and the partition is twice as big right?

All good!
Thanks!

It would be nice (just curious) to point to the board file in the kernel that did the usb poke

davidgf,

> Is the new uboot using the ENV partition?

No.

> Meaning, if I update the bootloader, will I loose
> all my env?
> I imagine the new uboot stores env at the end of
> the first partition, since its 512kb and the
> partition is twice as big right?

Right. You have to flash the new default envs image to start using the new envs. The entire 1 MB of mtd0 is reserved for the new u-boot and its envs.

And FYI, the stock envs are still there if you ever need them to boot stock.

All good! 
Thanks! 

It would be nice (just curious) to point to the board file in the kernel that did the usb poke

It is a hassle to dig out the old code :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi,

I have the same problem with USB not working. In my case I think something happened to probably my env beause one day I had to reboot my NSA320 and it would not start. Installing debian on a USB-stick did not work, it would not boot from that with the right USB boot settings, so i had to install it on a disk. Also after booting debian from disk I still did not have access to USB again.

I get nothing when in the log when I insert a stick, not with any stick, the USB-drivers do get loaded, but that is about everything.

So my question is, did you find aything about this "poke", so that I would be able to add it to the boot?

Cheers

bandicoot,

> I get nothing when in the log when I insert a
> stick, not with any stick, the USB-drivers do get
> loaded, but that is about everything.

A reminder, you have to mount the USB drive manually in the basic rootfs. Or setup an automount:

Wiki thread:

Quote

udev

Automount USB drives with udev rules using disk label

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

Thanks so much, i did not have to set up udev or automount. I did not see sdc/sdc1 appear. Reading up in the links you gave brought me to running

usbreset vendor:product

That did the trick, it looks like the usbreset in debian does power up the USB, and I found the message in /var/log/messages that sdc was found and I could mount it myself. At this moment i do not care much about the automount ;) .

But I would like to know how to power up usb in stock uboot, 'mw.l f1010100 0020c000' did not do the trick for the NSA320.

Cheers



Edited 1 time(s). Last edit at 03/17/2021 04:44PM by bandicoot.

bandicoot,

> Thanks so much, i did not have to set up udev or
> automount. I did not see sdc/sdc1 appear. Reading
> up in the links you gave brought me to running
>

> usbreset vendor:product
>

> That did the trick, it looks like the usbreset in
> debian does power up the USB, and I found the
> message in /var/log/messages that sdc was found
> and I could mount it myself. At this moment i do
> not care much about the automount ;) .

Cool! could you post the exact command you use for this (would be quite useful for others in the future):

usbreset vendor:product

> But I would like to know how to power up usb in
> stock uboot, 'mw.l f1010100 0020c000' did not do
> the trick for the NSA320.

It was long ago so I can't remember this. We have moved on to the new u-boot for quite a long time.

Once you got it running OK, you should install new u-boot:

https://forum.doozan.com/read.php?3,12381

But if you insist on staying with stock u-boot, then a similar command as "mw.l f1010100 0020c000" needed to be figured out (not hard at all).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi LillianCastrinio,

What did you do to update the driver? Did you update one of the mtdblock's to do that?

Cheers

bodhi Wrote:
-------------------------------------------------------
> bandicoot,
>
> > Thanks so much, i did not have to set up udev
> or
> > automount. I did not see sdc/sdc1 appear.
> Reading
> > up in the links you gave brought me to running
> >

> > usbreset vendor:product
> >

> > That did the trick, it looks like the usbreset
> in
> > debian does power up the USB, and I found the
> > message in /var/log/messages that sdc was found
> > and I could mount it myself. At this moment i
> do
> > not care much about the automount ;) .
>
> Cool! could you post the exact command you use for
> this (would be quite useful for others in the
> future):
>

> usbreset vendor:product
>

I found this in dmesg:

[   11.149411] usb 1-1: new high-speed USB device number 2 using orion-ehci
[   11.351049] usb 1-1: New USB device found, idVendor=05e3, idProduct=0608, bcdDevice=77.63
[   11.360065] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   11.367957] usb 1-1: Product: USB2.0 Hub
[   11.373450] hub 1-1:1.0: USB hub found
[   11.378296] hub 1-1:1.0: 4 ports detected

I installed:

apt-get install usbutils

And I used:

usbreset 05e3:0608

> > But I would like to know how to power up usb in
> > stock uboot, 'mw.l f1010100 0020c000' did not
> do
> > the trick for the NSA320.
>
> It was long ago so I can't remember this. We have
> moved on to the new u-boot for quite a long time.
>
>
> Once you got it running OK, you should install new
> u-boot:
>
> https://forum.doozan.com/read.php?3,12381

I will do that once I am up to it.

>
> But if you insist on staying with stock u-boot,
> then a similar command as "mw.l f1010100 0020c000"
> needed to be figured out (not hard at all).

I have been googling to find this for the NSA320, but there is about zero else then this command, which I read almost anywhere is for the NSA325. It may not be hard to figure it out, but to me it is, I have no clue to how to approach this. I have been using md.l to read at f1010100 , but the value after boot uboot is different, and I found on the internet that there are even machines where you have to write at 2 adresses.

Is there a way to do something like 'md.l f1010100' from a booted Debian?



Edited 3 time(s). Last edit at 03/18/2021 02:42PM by bandicoot.