Quantcast
Channel: Linux Device Hacking - Debian
Viewing all 26605 articles
Browse latest View live
↧

Re: NAS326 does not boot reliably

July 21, 2019, 1:53 pm
$
0
0
bodhi,
thanks for your advice.
I decided to give it a try hooking up my USB-TTL-interface to the serial port of my NAS326 box.
Don't know the chip but from the driver I assume it is a FT232.
If I hook it up and try to boot the NAS remains in a state with all leds shining continously which is,
if I understand the descriptions in the forum here, normal (waiting for commands on serial console).
That shows that it somehow detects that the interface is attached. If I remove the cable the box does boot.
However, I do not get any output coming from the serial port.
The pinout I used is the one you posted in an thread some years ago: 
Zyxel NAS326 Serial Pinouts (same as NSA325 and NSA310S/320S)

GND  
RX 
TX 

          +----+----+           
          |    |    |
+----+----+----+----+----+
|3.3V| TX | RX |    | GND|
+----+----+----+    +----+

I am not sure with TX/RX. Does "TX" mean here, TX from NAS326? In that case I would have to connect it with my FT232's RX and the other way around, right?
Is baud rate critical? I set it to 112500, 8N1.
Maybe my interface does only allow 5V operation? I also ordered a ch340g interface https://www.ebay.de/itm/252713824136 for testing.

All the best,
Michael
↧
Search

Re: NAS326 does not boot reliably

July 21, 2019, 9:26 pm
$
0
0
Michael,

Quote

> USB-TTL-interface to the serial port of my NAS326
> box.
> Don't know the chip but from the driver I assume
> it is a FT232.
> If I hook it up and try to boot the NAS remains in
> a state with all leds shining continously which
> is,
> if I understand the descriptions in the forum
> here, normal (waiting for commands on serial
> console).
> That shows that it somehow detects that the
> interface is attached. If I remove the cable the
> box does boot.

That is the behavior we expect from this box. When serial console connected, sometime it got stuck in the BootROM phase.

To "nudge" it to get pass this phase, on the box that you have serial console module connected. If it is a Linux box, then things are quite easy. Instead of running picocom/minicom/screen to be the serial console server, you would run kwboot in debug mode (I mentioned this in the installation instruction): 

kwboot -t -B 115200 /dev/ttyUSB0 -d

After a few seconds, it will continue booting.

Quote

> Zyxel NAS326 Serial Pinouts (same as NSA325 and
> NSA310S/320S)
>
> GND
> RX
> TX
>
> +----+----+
> | | |
> +----+----+----+----+----+
> |3.3V| TX | RX | | GND|
> +----+----+----+ +----+
> [/code]
>
> I am not sure with TX/RX. Does "TX" mean here, TX
> from NAS326? In that case I would have to connect
> it with my FT232's RX and the other way around,
> right?
> Is baud rate critical? I set it to 112500, 8N1.

Yes. baud rate and other setting are very important. 112500, 8N1 is correct.

> Maybe my interface does only allow 5V operation?

The power pin 3.3V must not be connected. It will fry your serial console port. The only pins we use are: TX (transmit), RX (receive), and GND (ground).

Depending on the serial module chip, you might need to reverse the TX/RX connection, or might not. The old CP2xxx chip serial module already reversed, meaning TX should be connected to TX, RX to RX. The PLxxxx chip module is always reversed, meaning RX should be connected to TX, TX to RX.

=====

Note: you don't have a Linux box to run serial console module then, you can also trick the box this way: disconnect the serial console module USB conector, and as soon as the box power up and start booting, plug it in, and run screen (Mac OS) or putty (Windows) to start serial console server. You will lose some log at the beginning, but serial console will work.
↧
↧

Re: NAS326 does not boot reliably

July 22, 2019, 12:14 am
$
0
0
bodhi,
many thanks for your advice! Great that you spend time to help others.
I actually had to reverse TX/RX pins and now serial console works like a charm.
I set change_boot_part to 0, rebooted several times and up to now it works. (consistently boots into custom kernel)
What I would really like to understand is what change_boot_part does.
In your installation instructions change_boot_part is set to 1 and it seems to work for most people.
I thought it is part of the mechanism
Quote

This also serves as a rescue system. Whenever the rootfs on USB has problem and cannot boot (the effect is just like the USB drive is not plugged in), the NAS326 will fall back to booting the kernel 1 or 2 in NAND. When this occurs, the u-boot envs in step 4 must be reentered at Debian command line again to allow booting back to USB rootfs.
So setting change_boot_part to 0 switches this mechanism off, right?
↧

Re: NAS326 does not boot reliably

July 23, 2019, 8:01 am
$
0
0
Michael,

No, the change_boot_part does not switch that off. Basically, that env was set to switch NAND kernel 1 to 2, and vice versa. When we set this to 0, we tell stock uboot to boot the current kernel which is curr_bootfrom=1.

Stock FW use this to upgrade kernel.
↧

Re: Dell Appliance

July 26, 2019, 10:59 pm
$
0
0
All,

I plan to revisit the 2GB RAM issue on this box. Please remind me in a few weeks if I forget.
↧
↧

Re: Dell Appliance

July 27, 2019, 6:01 am
$
0
0
Good to hear you plan to get back to this. I'd like to get mine going to boot from the internal flash card, Your file system from last year works fine from USB, but it would be nice to have the USB ports available. I'll follow.
↧

Re: Dell Appliance

July 27, 2019, 12:10 pm
$
0
0
bodhi Wrote:
-------------------------------------------------------
> All,
>
> I plan to revisit the 2GB RAM issue on this box.
> Please remind me in a few weeks if I forget.

Cool! I've been wanting to dig mine out for a while now, but other priorities keep getting in the way. I've been pushing my beloved Dockstar too hard and I'm tired of the OOM killer kicking in, so it would be nice to have 2GB of RAM. :-)

Let me know if I can help in any way.

-JT
↧

Debian on wrt1200ac

July 31, 2019, 11:16 am
$
0
0
Hi all.

Recently I installed Debian mvebu on my wrt1200ac.
Using dts from https://github.com/Chadster766/McDebian/tree/master/linux-4.19.12/arch/arm/boot/dts and kernel / rootfs 5.1.7 from bodhi (thanks!), I successfully booted and ran the OS. Almost everything works: ethernet switch, wifi (mwlwifi compiled as module), cpu speed, etc.

However the kernel reports less memory than other OSs: 
              total        used        free      shared  buff/cache   available
Mem:         376032       62060      107272        1448      206700      258396
Swap:             0           0           0

The router has 512mb ram. OpenWRT and mcdebian (https://github.com/Chadster766/McDebian) reports full ram capacity.

Any ideas?

Regards
fsonnlei
↧
Search

Re: Debian on wrt1200ac

July 31, 2019, 2:19 pm
$
0
0
Hi,

Starting point is a full serial log, from uboot init through loading of the kernel + with a openwrt boot as well. It's possible WRT is doing platform specific tricks, but hard to know without the log.
↧
↧

Re: Debian on wrt1200ac

July 31, 2019, 2:37 pm
$
0
0
Thanks. Attached files:
- fw_printenv from Debian Bodhi
- dmesg from Debian Bodhi
- dmesg from OpenWRT

Best,
fsonnlei
↧

Re: Debian on wrt1200ac

July 31, 2019, 2:45 pm
↧

Re: Debian on wrt1200ac

July 31, 2019, 10:20 pm
$
0
0
fsonnlei,

> Recently I installed Debian mvebu on my
> wrt1200ac.
> Using dts from
> https://github.com/Chadster766/McDebian/tree/master/linux-4.19.12/arch/arm/boot/dts
> and kernel / rootfs 5.1.7 from bodhi (thanks!),

Please describe how did you use the DTS from Chadster766 Github. Did you append the DTB to uImage? or did you use bootz? and where is that DTB come from?

And the log files you've posted made it difficult for me to figure out! you should do this instead:

- With serial console connected, power up, interrupt u-boot at countdown.
- Enter the envs you need to do to boot Debian.

- Print the envs 
printenv

- And boot 
boot

Let it boot all the way to Debian prompt.

And then capture the entire serial console log and post here (in code tag), don't attach log files.
↧

Re: Debian on wrt1200ac

July 31, 2019, 10:47 pm
$
0
0
I'm no expert, but I think the dts is doing something odd, in the dmesg it has; 

OF: fdt: Ignoring memory range 0x0 - 0x8000000

When booting Bodhi's kernel, but not the OpenWRT kernel. Bodhi's then has less memory pages set up, perhaps due to this range being ignored.

Which of those DTS' did you use?
↧
↧

Re: Debian on wrt1200ac

July 31, 2019, 10:55 pm
$
0
0
Quote

OF: fdt: Ignoring memory range 0x0 - 0x8000000

That's what my questions above are driving at. In the chain of DTS includes, somewhere there is a problem. I need to know how the DTB was created to find the wrong memory definition.

But first, the serial log should show the whole picture.
↧

Pogo Plug Power Connector Repair

August 1, 2019, 1:10 pm
$
0
0
Not Debian but I thought I would share an experience with a Pogo Plug power connector. This is for E02, V3 but not Mobile or V4, i.e. for plugs with a 120 V cord connected to the box.

One of my V3s would not boot and the power connector felt loose when inserting the cord. So I opened the case to investigate and found one of the pins of the cord connector had a loose solder connection; the pin moved when the connector was "wiggled". Re-soldered both pins and all is fine. I should have taken pictures but it's straightforward if you have opened a Pogo to get to the serial connector.

Lesson learned is to minimize use of the connector on the Pogo; use the other end of the cord or a switched power strip if you have to unplug often.
↧
Search

Transfer File System to a Different Box

August 1, 2019, 2:16 pm
$
0
0
I have a Pogo Mobile (Kirkwood) running Bohdi's Debian kernel and file system (4.4) as a streaming player that works very well. It took a fair amount of time to get the ALSA sound system installed and working with a USB DAC and the Squeezelite player client. I wanted to set up a Pogo E02 the same so I installed the file system from the Mobile backup onto a new USB stick. It didn't boot because the E02 uses a different DTS file than the Mobile; I should have checked this. (Both the boxes are running an older U-Boot.) I rebuilt the kernel with the correct DTS and it booted (green light on) but didn't get a network address, so no SSH. I found a thread on here from another user that tried this and Bohdi pointed out a problem with the udev rules and conflicting MAC addresses:

Quote

When you use an existing rootfs to boot another identical box, you will need to make sure the udev rules for persistent-net are removed or modified. This usually causes network problem because of conflicting MAC address.

To make it really simple, remove these 2 files (or rename them to *.save so that they will be regenerated by udev using the new MAC address) before mounting to the other box:
/etc/udev/rules.d/70-persistent-net.rules
/lib/udev/rules.d/75-persistent-net-generator.rules

I renamed the two files as suggested, but it still did not get on the network. There was a clue in dmesg (read from the stick in another Linux box) where it showed that the eth0 device was renamed to eth1. I looked at the 70-persistent-net.rules file again and found that the old definition from the Mobile was still there as eth0 and the new definition from the E02 was assigned to eth1. Since there was no definition for eth1 in /etc/network/interfaces, it didn't work. Also, the generator file had not been recreated; I renamed the old one back to the original name. I commented the line from the Mobile, moved the stick to the E02 and it got the network connection. Working 70-persistent-net.rules snippet: 
# Unknown net device (/devices/platform/mv643xx_eth_port.0/net/eth0) (mv643xx_eth_port)
#SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:31:05:be:f1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# Unknown net device (/devices/platform/mv643xx_eth_port.0/net/eth0) (mv643xx_eth_port)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:31:00:bd:cf", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

In the best troubleshooting tradition of changing two things at once, I also changed the interfaces file to specifiy the MAC address using the the hwaddress line in the static ip section. So, I'm not certain which one fixed it, but I'm pretty sure it was the udev rules.

All is fine now after sorting out a couple of USB DAC issues. I thought I'd post this in case anyone is thinking of doing something like this.
↧

Re: Transfer File System to a Different Box

August 1, 2019, 4:26 pm
$
0
0
mikeh49,

This issue has been thoroughly documented in the Wiki thread:

https://forum.doozan.com/read.php?2,23630

Quote

Backup and Cloning rootfs

CrashPlan 4.3.0
Backup/Restore rootfs using tar command
Adjust udev rules after cloning rootfs
Stock Pogoplug rootfs
How to clone a rootfs from one Kirkwood box to another: Step 1 and Step 2
How to clone SATA rootfs to USB rootfs

Did you try step 2? those 2 files needed to be modfied as described.
↧
↧

Re: Transfer File System to a Different Box

August 2, 2019, 8:10 am
$
0
0
I missed Step 2 and in my search I only found your post that deleted the 2 udev files (a couple of posts above the Step 2 post). After looking at Step 2, and with what I now know, I think all you need to do is comment the line in the persistent-net rules file that contains the MAC address of the "donor". A new line is then generated with the MAC of the new box.

In my case, the "donor" box persistent-net-generator file contained the KERNEL! line as in your example; I made no changes to that file.

Thanks for your help and all you do to support us with these devices.
↧

Re: Pogo Plug Power Connector Repair

August 2, 2019, 7:24 pm
$
0
0
I remember thinking it was attached in a very flimsy manner when I opened up one of my E02's. There are no anchor points holding it to the board, just the two power pins soldered to the board. It could definitely do with some kind of epoxy holding it down.
↧

Re: Pogo Plug Power Connector Repair

August 2, 2019, 10:39 pm
$
0
0
> Lesson learned is to minimize use of the connector
> on the Pogo; use the other end of the cord or a
> switched power strip if you have to unplug often.

Good advice :) I had one broken just like yours. I swapped the power supply from the old bricked Pogo E02 (I have multiple Pogo E02, V3 Pro and V3 Classic).
↧
Viewing all 26605 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>