What happened to the D-Link DIR-510L?


#81

19.0x is comming. Could someone tell exactly which gpio setup is proper?


#82

GPIO#0 and GPIO#8 should be floating, i.e. UARTF disabled.
So the power switch and USB will work, but we don't have battery status.

Battery status could be read by bit-banging the input e.g. from a userspace script, but since there is no standard way of handling battery in OpenWRT anyways (like ACPI for desktop; e.g. LuCI battery gauge, automatic clean shutdown etc.) it should not matter at the moment.


#83

@s_2

GPIO#0 and GPIO#8 should be floating, i.e. UARTF disabled.
So the power switch and USB will work, but we don't have battery status.

Battery status could be read by bit-banging the input e.g. from a userspace script, but since there is no standard way of handling battery in OpenWRT anyways (like ACPI for desktop; e.g. LuCI battery gauge, automatic clean shutdown etc.) it should not matter at the moment.

Done. I made changes and rebased to current master. Please tell me that everything is ok. :slight_smile:



#84

almost working :slightly_smiling_face:

I had to call
echo "1" > /sys/class/gpio/usb_enable1/value
after boot so that USB 1A and Power Switch would work, apparently it is currently set to output but 0 by default.
(Took quite a while to re-read and finally remember all that stuff regarding USB pins, though it's only been a few months ago... :stuck_out_tongue_winking_eye:)


#85

hello @All!

I've been reading this whole topic and i must say, that i am impressed by the skills you have in getting OpenWRT running on this router. My Usecase would be resharing WiFi access on cruiseships outside of the cabin, because you only get a single mac-bound device to use for a reasonable price. When going off-board i'd need to put an LTE-stick for internet access shared to multiple devices. However i am still having troubles and a few qustions.

I've managed to permanently solder a tiny USB-to-Serial bridge into the device so now i will always be able to connect via serial port to the device on the USB charging input port without opening the device. If there is interest on how i did this, i will be glad to share a tutorial with pictures on this.

Since i couldn't figure out, how to get the backup mtd0 dump mentioned in post #12 transferred via serial (http method was not working since /tmp/www3/ was non-existent in my stock firmware version), i just put a 2GB FAT formatted USB stick in, then:

mkdir /tmp/usb
mount /dev/sda1 /tmp/usb/
dd if=/dev/mtd0 of=/tmp/usb/dir-510l-whole-flash.bin

then rebooted and removed the stick.

However i never really found in this thread how the correct way would be to flash from stock to OpenWRT with the factory.bin file. So i ended up trying serveral methods, but none of them really worked. I had openwrt running after one try, but it was an old version of this thread and practially non-working. At some point i was at a bricked state, so i took out my SPI flash programmer and tried to rewrite the whole mtd0 file back to the chip, then reconnecting it. I guess the dump should be ok (i hope!), as the content seems to be ok when having a look at the start hex addresses of the 7 mtd partitions. Well at least it is talking to me again via serial, but i'm still is stuck right behind the bootloader, where the serial console says:

CDM56CDL_U03 Jboot B796
JRecovery Version R1.2 2013/10/04 18:32
SPI FLASH: MX25l12805d 16M
....Boot addr = 0x80400000

E:-100
IP=192.168.123.254 NA=78:54:2E:FF:FF:FF

No matter which image i flash through the mini HTML interface or the SPI flash programmer: the mtd0 backup, an OpenWRT factory.bin, a D-Link firmware image, nothing seems to get it alive behind the bootloader anymore, even if the flash is supposed to be successful either by browser-flash or SPI programmer. I am well aware about the 7 mtd partitions and tried multiple manual flash layout compositions with a hex editor of the mtd layouts, according to the address map found on the openwrt device page.

I have 4 flash chips of the type MX25L12835FMI-10G SOP16 used on the DIR-510l, because i already assumed things might not work out like a charm. All of them seem to be ok according to the flash programmer, so they seem to be intact.

I thing i've tried every idea i might get, but i'm still stuck.
I was hoping to get some suggestions from here.
Thanks!


#86

That sounds weird, actually all of the images linked in this thread should not brick the device (unlike the very early images in the old forum).

Is there any difference in the serial output depending on whether the reset button is held down during power-on?
In this device, the recovery is a separate partition as it also contains WiFi drivers, i.e. if you keep holding down the reset button during power on, the led should eventually start flashing orange and there would be an open Wfi network called DIR510L, which lets you upload the recovery image.

The problem with the old "brick" images was apparently that it would not even boot into normal mode when the recovery partition was overwritten (since it was not expected to be important when defining the flash layout for building OpenWRT images, as there seemed to be normal uboot etc. partitions like in other routers).

These recovery interfaces sometimes also have problems with modern browsers, it might help to try a different browser (ancient version of Internet Explorer, or curl -F ) to upload the firmware image.

Does the recovery flashing look normal on the serial console output? It should take quite a while as JBoot seems to be rather slow...


#87

This look like broken config partition. I had similar situation on DWR-118.

I found full flash dump from old forum:
http://174.137.163.116/bootloader.bin
This is mtd0 dump. It should be working. Please try this.

Damn! So close! :smiley:

Stupid mistake. I made new images. Links are the same.


#88

Sorry for the late response, there was no power at all.on the usb ports.

however, I tried to cross-compile the flashfiles from @chkdsk88s github 510l branch and am not able to add luci as a package. The provided last files seem also not to have a webinterface. Might there be an issue, or maybe I am failing doing it correctly?

For me the battery state LED seems to work.

Is it possible to add a wan status to the other LED, like Green if Wan is connected, yellow if just an access point is connected with no WAN access, and RED if not connected, or something more clever.

I think it would look nicer if we can optically see the WAN Status from a LED.

Great Job so far! Thanx


#89

Sysupgrade image is working fine so far on my main test device; USB, Wifi and Power switch all working :slightly_smiling_face:

Could you check whether the factory image was actually rebuilt from the latest sysupgrade, or could it possibly be older?
I tried flashing it to the other DIR-510L I have (case never opened), but the network stack was behaving weird and it couldn't switch off (however pressing the reset button shortly would switch it off after a short while, so there was no need to open the case).

I hope it's just a version mismatch; I guess both images should be exactly the same except for the 72 bytes factory header!? If so, then fortunately they are not :grin:

Try

 ./scripts/feeds update -a
 ./scripts/feeds install luci

before running make.

Also, yes, there is no luci by default in the snapshot images, only in the stable builds from the official downloads page.
And it can be frustrating to try to install packages via opkg on snapshot images, especially if you built it yourself (afaik you basically have to use your local-built packages, or be lucky that the ones from the web happen to work with your build, i.e. nothing / just minor things were changed in between)


#90

Thank you so much for your ideas!

So i found out that my main problem was the integrated TTL-USB Adapter i was mentioning before. For some reason the DIR-510L didn't like something about the power drain of the serial adapter being soldered to the charging usb port. I have desoldered it and connected separately. It is now booting any flashed image. Odd: Integrating a serial adapter to the mainboard has been working on other mobile routers, but whatever...

So now i brought everything back to life with flashing my dumped mtd0 with a SPI programmer. The stock firmware runs flawless again. But as soon as i flash the factory.bin from @CHKDSK88's post #83, i end up in a boot loop with this console output:

CDM56CDL_U03 Jboot B796
JRecovery Version R1.2 2013/10/04 18:32
SPI FLASH: MX25l12805d 16M
.
...Boot addr = 0x80400000
...................
Starting kernel @80000000...
[    0.000000] Linux version 4.14.101 (krolik@ubuntu-VirtualBox) (gcc version 7.4.0 (OpenWrt GCC 7.4.0 r9395-8911b734c5)) #0 Mon Feb 18 10:45:06 2019
[    0.000000] Board has DDR2
[    0.000000] Analog PMU set to hw control
[    0.000000] Digital PMU set to hw control
[    0.000000] SoC Type: MediaTek MT7620A ver:2 eco:3
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 00019650 (MIPS 24KEc)
[    0.000000] MIPS: machine is D-Link DIR-510L
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 08000000 @ 00000000 (usable)
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[    0.000000] Primary data cache 32kB, 4-way, PIPT, no aliases, linesize 32 bytes
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000] random: get_random_bytes called from start_kernel+0x8c/0x474 with crng_init=0
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 32512
[    0.000000] Kernel command line: console=ttyS1,57600 rootfstype=squashfs,jffs2
[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Writing ErrCtl register=0007f020
[    0.000000] Readback ErrCtl register=0007f020
[    0.000000] Memory: 124748K/131072K available (3671K kernel code, 168K rwdata, 856K rodata, 160K init, 207K bss, 6324K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS: 256
[    0.000000] CPU Clock: 580MHz
[    0.000000] clocksource: systick: mask: 0xffff max_cycles: 0xffff, max_idle_ns: 583261500 ns
[    0.000000] systick: enable autosleep mode
[    0.000000] systick: running - mult: 214748, shift: 32
[    0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6590553264 ns
[    0.000009] sched_clock: 32 bits at 290MHz, resolution 3ns, wraps every 7405115902ns
[    0.015470] Calibrating delay loop... 385.84 BogoMIPS (lpj=1929216)
[    0.087721] pid_max: default: 32768 minimum: 301
[    0.097107] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.110132] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.129550] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.149029] futex hash table entries: 256 (order: -1, 3072 bytes)
[    0.161199] pinctrl core: initialized pinctrl subsystem
[    0.172013] NET: Registered protocol family 16
[    0.715326] mt7620-pci 10140000.pcie: PCIE0 no card, disable it(RST&CLK)
[    0.728558] mt7620-pci: probe of 10140000.pcie failed with error -1
[    0.758179] rt2880_gpio 10000600.gpio: registering 24 gpios
[    0.769216] rt2880_gpio 10000600.gpio: registering 24 irq handlers
[    0.785073] clocksource: Switched to clocksource systick
[    0.796619] NET: Registered protocol family 2
[    0.806013] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[    0.819791] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[    0.832383] TCP: Hash tables configured (established 1024 bind 1024)
[    0.845194] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.856694] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.869393] NET: Registered protocol family 1
[    0.880663] rt-timer 10000100.timer: maximum frequency is 1220Hz
[    0.893372] Crashlog allocated RAM at address 0x3f00000
[    0.905567] workingset: timestamp_bits=30 max_order=15 bucket_order=0
[    0.923426] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.934930] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    0.964201] io scheduler noop registered
[    0.971906] io scheduler deadline registered (default)
[    0.982969] gpio-export gpio_export: 2 gpio(s) exported
[    0.993499] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    1.006976] 10000500.uart: ttyS0 at MMIO 0x10000500 (irq = 13, base_baud = 2500000) is a Palmchip BK-3103
[    1.026601] 10000c00.uartlite: ttyS1 at MMIO 0x10000c00 (irq = 20, base_baud = 2500000) is a Palmchip BK-3103
[    1.046286] console [ttyS1] enabled
[    1.046286] console [ttyS1] enabled
[    1.060046] bootconsole [early0] disabled
[    1.060046] bootconsole [early0] disabled
[    1.076487] cacheinfo: Failed to find cpu0 device node
[    1.086762] cacheinfo: Unable to detect cache hierarchy for CPU 0
[    1.104239] spi spi0.0: force spi mode3
[    1.112656] m25p80 spi0.0: unrecognized JEDEC id bytes: e1, 10, 0c
[    1.125063] m25p80: probe of spi0.0 failed with error -2
[    1.136372] libphy: Fixed MDIO Bus: probed
[    1.152040] gsw: setting port4 to ephy mode
[    1.160474] mtk_soc_eth 10100000.ethernet: generated random MAC address c6:f7:d7:35:4d:67
[    1.176863] mtk_soc_eth 10100000.ethernet: loaded mt7620 driver
[    1.189306] mtk_soc_eth 10100000.ethernet eth0: mediatek frame engine at 0xb0100000, irq 5
[    1.206317] rt2880_wdt 10000120.watchdog: Initialized
[    1.217636] NET: Registered protocol family 10
[    1.230171] Segment Routing with IPv6
[    1.237647] NET: Registered protocol family 17
[    1.246574] 8021q: 802.1Q VLAN Support v1.8
[    1.257651] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[    1.272639] Please append a correct "root=" boot option; here are the available partitions:
[    1.289297] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    1.306539] Rebooting in 1 seconds..

Any suggestions?


#91

Please use "Preformatted text </>" for logs, scripts, configs and general console output.
grafik

Please edit your posting accordingly.


#92

Your flash isn't recognized in kernel. Could You read flash name from IC at the PCB?

EDIT:

@lowmaster write, that USB ports are disabled. @s_2, do You confirm that?

I checked and it is good image. There are two differences: in factory You have factory header. In sysupgrade You have metadata at end.

Could You try one more time from d-link stock firmware web gui upgrade?

You can customize it in Your device from userspace.


#93

The charging port connects to a TI BQ24195L controller, which will detect the power source according to USB battery charging specifications, i.e. it can actually speak USB to negotiate the current usage with the host controller.
I think you would need the source code for MSP430 to build your own firmware, so it can talk to that chip via I2C and disable that feature, so your USB-UART could also work normally... :grin::sweat_smile:

I will revert my main testing device back to stock in the evening and test the factory image on that one. Apparently the sysupgrade was only working flawlessly on my device due to the existing configuration...

...or could there be actually multiple variants of this device and we just didn't notice until now? :thinking: :innocent:


#94

Thank you!

Thanks for the hint on the log, i was suspecting so. Actually it seems that my additionally ordered flash chips are not of the exact same type, despite they carry same model no. on their printing.
So i don't think that there are other variants of the PCB. I will try the chip that i originally desoldered from the board, just didn't want to touch it as i preferred working with backups, just in case.

I still wonder why the original DLink image is working. I still have much to learn - why does the chip need to be probed? And why is the probe reseponse negative if the chip specs are basically the same? Can these ID bytes be changed with a SPI programmer to trick the probing? I've read that probing takes place on the bootloader level, but the log says that we are already in kernel. If it is in the kernel, can the JEDEC ID just be added to a list with compatible chips, and then recompiling the image? As you see, I have troubles understanding in how the problem originates. I might already be off-topic, but don't know the right place to ask these questions. Sorry for that.


#95

That's very interesting, I had always assumed that

compatible = "jedec,spi-nor";

in the .dts would somehow automagically query the chip for its size, but it turns out it will actually just lookup the ID from a hardcoded table:
https://elixir.bootlin.com/linux/latest/source/drivers/mtd/spi-nor/spi-nor.c#L1266

Thus, when searching openwrt on github for "spi-nor" there are lots of patches already that simply add new flash IDs, e.g.:

Apparently you will have to add 0xE1100C for your flash chip in spi-nor.c (which I cannot find in the OpenWRT repository, seems to be packaged?).

So maybe you could just try

compatible = "m25p128-nonjedec";

instead and hope it will accept your flash :grinning:


#96

Okay, I have reflashed both devices to stock firmware, then back to the latest factory image.
Both are working and behaving the same now, and both USB ports are working on boot :slightly_smiling_face:

Just cannot install packages using opkg for now, but that will be fixed with the official 19.0 release builds anyways...

So I think it is finally time for a PR :slightly_smiling_face:
Thanks to everyone contributing and testing! :+1:


#97

Done:

Great team work guys. :slight_smile:

@molocho

This jedec is unknown for kernel. I think, @s_2 solution could You help.
But IMO You should return it to store or ask for refund.


#98

Now this is interesting:
I have put in the original flash chip and still get this:

[    1.013187] m25p80 spi0.0: unrecognized JEDEC id bytes: e1, 10, 0c
[    1.025595] m25p80: probe of spi0.0 failed with error -2

I might have a different flash chip on my board than other exemplars of this router:

The originial flash chip of my particular unit is of type MX25L12835F, reporting JEDEC ID 0xc22018
My 3 backup chips are of type MX25L12835E, also reporting JEDEC ID 0xc22018, so they should practially be the same.

exact readings from "AsProgrammer" tool for all 4 of my chips are:

Current programmer: CH341
ID(9F): C22018
ID(90): C217
ID(AB): 17
ID(15): 0707

The bootlog from the stock firmware also says:

deice id : c2 20 18 c2 20 (2018c220)
MX25L12805D(c2 2018c220) (16384 Kbytes)

Seems i am out of luck until i manage to implement support for these chips - if the suggested idea from @s_2 works - or get another chip which is supported. Datasheets seem to be online for the SPI's i am struggling with. I am curious what type of SPI chips are used on other DIR-510L devices you guys are tinkering with.


#99

If your programmer reads the correct value 0xC22018, this should be a hardware issue, as 0xE1100C is not a registered JEDEC ID (but I had't bothered yet as that could be anything when the chip comes from China :grin: )

Actually, the bits are just shifted by one:

       c2        20        18
       e1        10        0c
1100 0010 0010 0000 0001 1000
1110 0001 0001 0000 0000 1100

So there is either a CPOL issue with SPI (stock bootlog says it uses SPI Mode 3), or you have some issues on the SCK pin. Maybe there's a short from SCK to GND or VCC with a certain resistance, so that there is no full transition of the logic level, but it goes back immediately after a very low spike, and this returning to the shorted value could be interpreted as the following edge that would trigger the sampling. But then again that's just crystal ball reading after all :stuck_out_tongue_winking_eye:

Since the problem persisted between soldering, it might be damage or shortage to the traces near the pads?

When did you read the value from the stock bootlog, i.e. does it actually still boot successfully with stock firmware?

Maybe there's a timing difference between stock and OpenWRT that weirdly compensates for this in the stock firmware... :thinking:


#100

Maybe clock is too high for this memory? :thinking: