I wonder what "And some of the images still have this bug." is supposed to mean, probably DCS-930/932 is not even considered working at the moment...
Actually the same applies to the current stable release images available for download - they just don't work since the kernel partition apparently grew too big and was truncated during image generation without raising any warning, resulting in lzma error on boot.
I had already considered reporting this device to the thread Report Devices Here With 18.06.0 Provided Image too big to save overlay but then again I'm not even sure whether the factory partition is actually the problem, or rather the kernel (or both?)...
Maybe you're lucky trying to change the profile name for the device, or building the whole system (including toolchain) as this might be just an issue with imagebuilder, so that maybe other profiles would cause mipsel-openwrt-linux-musl-cpp to be built, which could then be used for DCS930 image generation...
You should also try to exclude packages for pppoe, ipv6 etc. as your image might become too big to boot, even when it was "successfully" created.
I tried the already build image what I downloaded from the wiki, but when I load it through the emergency web interface it is not working, still the old Dlink firmware comes back,
that's why I though when I will build a custom image without ipv6, pppoe etc.. :
@nrbrtbjcs, read carefully the important information that @s_2 posted
Unless you can magically create a kernel that is functional and smaller than that allowed for the device, it isn't going to run OpenWrt. The image builder does not build from source. If you want to try yourself, the full build environment is the best way to go.
This is a browser issue with the emergency web interface, it will not work with many current browsers anymore, regardless of which firmware you are trying to flash (even vendor firmware).
Try uploading the image with curl -F firmware=@/path/to/factory.bin http://192.168.0.20/
This way, you should at least be able to make the vendor firmware stop working after flashing stable OpenWRT from the officials downloads site - as far as I remember, you would get an lzma error when extracting the kernel on boot since the image was cropped, but maybe this was fixed in 18.06.2.
Let me know if it works with your custom build though, I also have a few of these devices
The WEB server is shuting down and the firmware updating will start immediately. Please DO NOT POWER OFF the device. And please wait for seconds...
but the device is now unoperational.
all LEDs are on,
I think I will need to dismount the device and connect the console.
also the emergency web interface is not working anymore, I think that was a feature of the old firmware,
When I will connect the console to the device can I still flash a firmware for ex. with TFTP ?
or how to recovery it please ?
Thanks and Have a great weekend.
This should actually keep working no matter what flash file you uploaded via the emergency / stock web ui, even the A1 and B1 versions seem to have the same flash layout.
Serial console would be helpful of course to see what's going on, but if the bootloader somehow got corrupted (whatever would cause this when using the stock emergency room) you might need one of those $2 CH341 flashers (SOP8 clip recommended, on this camera it works without soldering )
Sorry, my fault, the emergency interface is working fine, just the ping is not working for the interface, but I was able to get back the stock firmware.
when I flashed back the stock firmware, all my settings are back also.
I tried again flash the openwrt one, and after the flashing all LEDs are just on, and the camera is not operational, tried several times also reboot, nothing,
partition is not actually required for the bootloader to work (unlike config / u-boot-env from 0x30000 - 0x40000), by removing it from the mtd layout we could have additional 64 kilobytes for OpenWRT, not sure if it's worth the effort
you could check the sizes of the individual image parts in your build dir, which are used to generate the factory / sysupgrade images, and make sure kernel is not larger than 1344 kilobytes (apparently kernel and rootfs are always separate partitions for this device, no idea how to change that).
why does rootfs start within the kernel region? maybe the layout is just broken so that no warning will be triggered, but the kernel is overwritten by the rootfs partition if kernel is larger than 1024 kilobytes
Can I somehow modify the existing firmware bin file directly ?
because I am still having the above error with the image builder... and I cannot build a new firmware
now trying to establish the full build environment ...
Current snapshot kernel for ramips_rt305x is 1447 kilobytes, so I think you'd have to change the mtd layout, not sure whether this can be done with imagebuilder (creating updated .dtb)... or disable stuff like IPv6, PPPoE etc.
Just tried building DCS-932L from scratch, but could not find much in make kernel_menuconfig that would make the image smaller. Actually it seems most of the kernel modules are really located in rootfs and removing them would just make the filesystem smaller, not the kernel...
Kernel is 1299588 Bytes but apparently still too big:
U-Boot 1.1.3
Board: Ralink APSoC DRAM: 32 MB
relocate_code Pointer at: 81fb0000
******************************
Software System Reset Occurred
******************************
spi_wait_nsec: 42
spi device id: c2 20 16 c2 20 (2016c220)
find flash: MX25L3205D
raspi_read: from:30000 len:1000
.raspi_read: from:30000 len:1000
.============================================
Ralink UBoot Version: 4.1.2.0
--------------------------------------------
ASIC 5350_MP (Port5<->None)
DRAM_CONF_FROM: Boot-Strapping
DRAM_TYPE: SDRAM
DRAM_SIZE: 256 Mbits
DRAM_WIDTH: 16 bits
DRAM_TOTAL_WIDTH: 16 bits
TOTAL_MEMORY_SIZE: 32 MBytes
Flash component: SPI Flash
============================================
icache: sets:256, ways:4, linesz:32 ,total:32768
dcache: sets:128, ways:4, linesz:32 ,total:16384
##### The CPU freq = 360 MHZ ####
estimate memory size =32 Mbytes
Signature: DCS-930 B1 932L Release 1.12 (2016-02-25)
Please choose the operation:
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.
You choosed 3
0
3: System Boot system code via Flash.
## Booting image at bc050000 ...
raspi_read: from:50000 len:40
. Image Name: MIPS OpenWrt Linux-4.9.85
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 2863338 Bytes = 2.7 MB
Load Address: 80000000
Entry Point: 80000000
raspi_read: from:50040 len:2bb0ea
............................................ Verifying Checksum ... OK
Uncompressing Kernel Image ... LZMA ERROR 1 - must RESET board to recover
So I wonder if anyone has an idea what could be removed to make it smaller, or how the mtd layout could be changed to make it work. The sysupgrade.bin is only 3.0 MiB, so there should be some space remaining even in the tiny 4 MiB flash besides uboot and config?!
I would like to mod the firmware to use http post for uploading images instead of ftp. Found this old thread and was wondering if anyone has had success in downscaling the 930 firmware to the 4MB flash?
I am hope my new module could be smaller than email/ftp upload, but it would be nice to know if someone had any luck in building anything for this hardware recently. Another way could be branch an older version of OpenWRT and then figuring out what fixes in more recent versions are important and should be brought into the branch together with my new http post module.
After a ton of issues I finally got this device working today (A1 version). Will make a separate post with more details and provide a link back here too. I got mjpg_streamer running fine so you could at least poll data from the camera. it does not consume much CPU at all, so one way to do what you're looking for would maybe be to use curl or wget to locally connect to the stream, and http post that somewhere.
Awesome, thanks!
Still had this device in my backlog but couldn't find the time yet.
I guess you had to use OKLI since the kernel image grew too big for the latest versions? (resulting in LZMA ERROR 1)
Regarding DCS-932L, I wonder if ambient light sensor and IR-cut filter GPIOs are known already, or whether this even works autonomously in hardware. Guess I'll have to dig out my cameras again
I was lucky enough to have an old working firmware that I could use as an initial image, and the sysupgrade to a recent OpenWrt version from there. This so far only works on DCS-930 A1, but I have two B1 versions too that I hope to get working. not sure if DCS-932L is A1 or B1 version, but I'm guessing the sae approach should work there too.
- as far as I remember, you would get an lzma error when extracting the kernel on boot since the image was cropped, but maybe this was fixed in 18.06.2.
