Support for D-link DGS 1210-10P rev C1

Hello sir. Recently, I bought a gigabit switch for myself as they are cheap these days. I'm trying to install openwrt to connect my isp fiber directly on one SFP port and create a pppoe connection on the switch. Sadly enough it isn't supported via the openwrt team. Can anyone help me or direct me in this matter?

the device has :

  1. Broadcom cpu
  2. 128MB DRAM
  3. 32MB Flash memory

You can start here by identifying all the chips... Broadcom is often not a good start, though.

https://openwrt.org/docs/guide-developer/add.new.device

C1…I can pretty much guarantee you are in a dead end on this.

Broadcom SoC switches will never be supported by the switch project. The only switch SoC we support is the Realtek ones, but they was introduced by the D-Link engineers with the F1 hardware.

But C1 is a very old hardware, it is like 3-4years ago F1 was the delivered as new hardware from stores.

Lastly if you're not disturbed can I port ddwrt or any other custom firmware on a Huawei xpon onu?

Sure you can, if you actually can do it.

Hint(s):

  • there is no such thing as a "Huawei xpon onu", Huawei is a big company, they build more than a single device - and details will differ between them
  • Huawei likes to use their own in-house SOCs, for which no drivers exist (opensource contributions have also been hindered by US restrictions)
  • like cable modems, GPON relies heavily on signed drivers/ firmware, so potential success questionable to begin with
  • you're posting at forum.openwrt.org, we aren't specialists on what is supported- or possible on other 3rd party firmwares
  • someone will still have to do the development work, if in doubt, that someone will be you - or no one. That's valid for any device, either it is already supported or it isn't - in which case you can either accept that non-support or start developing on getting it supported. It's unlikely that you can convince anyone else to go out, buy this particular device with their own money and then spend somewhere between a long rainy weekend or several months (years) on working on it, even less if the actual hardware specs aren't known yet.

Technically it might even be realistic to get these Broadcom switches or even their preceding Marvell switches supported by OpenWrt, there is partial kernel support for many of these SOCs and if flash/ RAM are sufficient, it might be possible. However, no one has (really-) tried so far - and it will be a quite massive development effort as well (getting these realtek switches supported hasn't been a walk in the park either, and their current state is not great, but it has originally been fueled by very determined and motivated developers, who made the impossible possible).

In general, never bet on future device support, that's just doomed to fail. Either a device is already supported (down to the exact model number and hardware revisions!), at least in main (snapshots), or it isn't. If it isn't, yet, it's up to you to investigate if there are already ongoing efforts to support it (best case) or to check what's the hardware inside, to evaluate if there'd even be a remote chance of getting it support.

  • if it's 'just' a new device of a well-known/ supported SOC, with supported wireless chipsets, it's reasonable for a relative newcomer to start working on it, it'll be a steep learning curve, but there are realistic chances of success
  • if it's a well-known/ known-unsupported SOC (or unsupported wireless), chances of success are just about zero (unless you really want to dive in deep and dedicate months++ for working on this)
  • (if it's an interesting new SOC from Mediatek or QCA, you might find like-minded developers who might want to work on it as well)

But in either of these cases, development can only happen, if there's someone with the device on their desk, accepting the risk to break it in the process, and being motivated enough to spend significant time on hands-on development on it. If in doubt, it's only the weird bloke looking at you in the mirror, when you brush your teeth.

1 Like

Thank you for your patience brother and your effort.
I'm hesitant but not totally denying that fact that I'm not going to jump to develop it. That's why I bought 2 of them. But the main thing is I'm not a dev and the process isn't documented in detail That's why I'm poking through the forums hoping to find help.

There can never be a detailed documentation for that, it always depends on the hardware in question. The steps are always:

  • investigate what hardware is used
  • document the heck out of the running OEM firmware
    • take backups of the flash contents, of everything
    • boot logs, playing around on the OEM firmware via shell access, if possible
    • bonus points if you can get the vendor's GPL tarball (and if that is actually 'working', you might have to assemble multiple different tarballs across similar models and from other vendors, to fill the gaps)
    • find out recovery methods, bootloader access, serial access, anything to transport and boot an initramfs image to the device
  • check the git history what had to be done to get other similar devices working
  • everything beyond that is SOC- and device specific
  • you are basically on your own, because no one else has these devices on their desk and could provide 'general' advice, it's part of the unavoidable learning curve
  • keep in mind, you're working on live- and fragile electronics, often with mains voltage involved (openframe PSU)

https://openwrt.org/docs/guide-developer/adding_new_device
https://openwrt.org/docs/guide-developer/add.new.device


(almost) always required:

  • tools to open the case, somehow (can be 'fun')…
  • (small tip) soldering iron and -equipment
  • dupont (2.5mm pitch or 2.0mm pitch, depending on the device) pins and cables
  • usb2serial adapter, ideally with 1.8V, 2.5V 3.3V and 5V support, never hurts to keep multiple (different) ones of them
  • spi writer for the required voltage (and/ or voltage level shifters, if necessary), clamps/ adapter PCBs as necessary