Closed Juumm closed 4 years ago
@TRSx80 i bought two the same as yours. I cannot get demo.bin to flash. I will try more today. I have set my server to china in xiaomi home app and they work here in uk so the ip check for region is not blocking their use here. Worst case is i can still use the xiaomi home but ideally i want home assistant integration.
Can users with T20 and T20L grep their dmesg for the clock speeds please?
[ 0.000000] CCLK:712MHz L2CLK:356Mhz H0CLK:200MHz H2CLK:200Mhz PCLK:100Mhz
This is T20L on CFW. Looks like it is clocked lower than T20. So "L" stands for low-end
It may get a lower clock when you flash a firmware meant for older generations. Should really be 1000 Mhz.
@jmtatsch my cam has not been flashed and the clock speed is 712Mhz:
[ 0.000000] CCLK:712MHz L2CLK:356Mhz H0CLK:200MHz H2CLK:200Mhz PCLK:100Mhz
I dont think the cam liked my 64GB sdcard, I think there may be something wrong with it, never mounted. so my attempts to flash demo.bin didnt work:
p1
[ 14.329189] FAT-fs (mmcblk0p1): Can't find a valid FAT filesystem
[derek]mount return msg:0
[derek]test_if_device_can_use:ls -l /dev/mmcblk0p1 2>&1
[derek]test_if_device_can_use:brw-rw---- 1 root root 179, 1 Jan 1 1970 /dev/mmcblk0p1
:res:72
SD can be used now ^-^
I have another sd card to try but first I dumped firmware and save a full boot output on my google drive in case anyone can benefit from it.
@TRSx80 i bought two the same as yours. I cannot get demo.bin to flash.
Have you tried the suggestions in Installation - Community Tips?
I have not tried yet, I wanted to try and help with troubleshooting / pulling data off original firmware before attempting anything. But I will let you know if/when I have success (or not). I do have 2 of them, so maybe I will try with one soon.
It may get a lower clock when you flash a firmware meant for older generations. Should really be 1000 Mhz.
I had to go to another computer to make sure, but mine is also 712 MHz and mine is a pretty new Xiofang 1S (see pics above), still on stock:
[ 0.000000] CCLK:712MHz L2CLK:356Mhz H0:200MHz H2CLK:200Mhz PCLK:100Mhz
I am starting to wonder if it's really an L variant at all, or if that was just Chinese Aliexpress sellers telling BS. I have had my doubts from the beginning.
I think there are some ways you can look up the numbers on the chip in some reference materials to see what they really are. Maybe I will try to do that today. Not that it helps us identify in software for our purposes here, but just because I'm curious.
This is the best picture I could get of the markings on the processor whether its a T20L or not IDK, best bet is to compare cpuinfo with a known one. I now have successfully flashed one. I used the demo.bin from this thread Also copied over the drivers zip contents from this thread too into the normal firmware_mod/driver. The 64GB sd card i was using before didn't work for flashing, didn't mount either, it may be faulty because my dashcam had issues with it. i found another 16gb card and that was fine but it died after a few reboots, so I went to shops and bought two more 16gb which seem to be ok. Video works fine up to 1600x900. audio from the mic works. Audio to the speaker does not work. I tried all the different audio formats rebooting in between. also removed all filters in case it was that. I set a sound on bootup and I get a brief high frequency noise on reboot though. boot and msgs for a few minutes attached. I am going to configure it into home assistant and test for stability. I'm very impressed with the video quality it seems better than the standard output in the xiaomi home app.
fangboot4.txt
This is the previous boot log where I flashed, the one in the last reply shows the sdcard failure fangflash.txt
Hey guys. Just want to let you know that I just flashed my T20L 64MB with opensource uboot xiaofang1s_64mb_v2.bin, configured it with these settings: https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks/issues/573#issuecomment-527220706 and now I have working 1080p rtsp stream via "stock" v4l2rtspserver. I don't know why manual says that 1080p on 64MB cams is not possible...
Hmmm... And after flashing bootloader my clock went up:
[root@XiaoFANG:~]# dmesg | grep "Mhz"
[ 0.000000] CCLK:860MHz L2CLK:430Mhz H0CLK:200MHz H2CLK:200Mhz PCLK:100Mhz
[root@XiaoFANG:~]# cat /proc/cpuinfo
system type : bull
machine : Unknown
processor : 0
cpu model : Ingenic Xburst V0.1 FPU V0.0
BogoMIPS : 858.52
From what I heard uboot does hold settings for all hardware including CPU clock. Looks like it is true and we can overclock/underclock CPU using uboot...
Hey guys. Just want to let you know that I just flashed my T20L 64MB with opensource uboot xiaofang1s_64mb_v2.bin, configured it with these settings: #573 (comment) and now I have working 1080p rtsp stream via "stock" v4l2rtspserver. I don't know why manual says that 1080p on 64MB cams is not possible...
So, you've used uboot xiaofang1s_64mb_v2.bin+firmware_mod+settings and 1080p works OOB?
So, you've used uboot xiaofang1s_64mb_v2.bin+firmware_mod+settings and 1080p works OOB?
Exactly. 2000 bitrate is a little bit low for when is dark and the image is noisy, but its perfect at a daytime. And the snapshots in the dark works well.
Hey guys. Just want to let you know that I just flashed my T20L 64MB with opensource uboot xiaofang1s_64mb_v2.bin, configured it with these settings: #573 (comment) and now I have working 1080p rtsp stream via "stock" v4l2rtspserver. I don't know why manual says that 1080p on 64MB cams is not possible...
In that reply #573 (comment) they said that they flashed flashed Xiaofang 1S 64mb v2
Bootloader MD5: 3319029f732aa79df1377d613a8ad8e8
When I download that bootloader my md5 is 1b3fcafab119afd36bf4270c1d3c4da1 which is what is written Compiled Bootloader there is no bootloader there with that md5 ending in 8e8. Am I missing something here, its been a long day. My v4l2rtspserver-master is not working since I flashed that bootloader, vlc shows black screen then times out. I can see the connection in netstat on the camera. I flash the original bootloader back and its working again.
@spattinson Did you renamed your uEnv.bootfromnand.txt to uEnv.txt and edited its content with mem=39M@0x0 ispmem=5M@0x2700000 rmem=20M@0x2C00000
?
As for bootloader's md5 - 1b3fcafab119afd36bf4270c1d3c4da1 is correct.
@spattinson Did you renamed your uEnv.bootfromnand.txt to uEnv.txt and edited its content with
mem=39M@0x0 ispmem=5M@0x2700000 rmem=20M@0x2C00000
?As for bootloader's md5 - 1b3fcafab119afd36bf4270c1d3c4da1 is correct.
Yes to both, I stopped a few services free up memory and found the the rtsp works better. but still not fullhd and not working at 1600x900 either. For now I have put back the memory settings I had with stock, it seems to be more reliable at higher resolutions. The memory stuff is in the bootloader isn't it? setting it different on the commandline override that i guess. I think I'll settle for lower resolutions because I want to use mqtt for home assistant anyway. But I am happy to do more testing. currently I am using the drivers.zip package in my driver folder. I have not tried without that yet, ie vanilla firmware_mod
Hmm... I've got 1600x900 working with a stock bootloader without any other modifications no problem. My stock bootloader have this settings: mem=41700K@0x0 ispmem=8M@0x28B9000 rmem=15644K@0x30B9000
. Is yours the same?
Hmm... I've got 1600x900 working with a stock bootloader without any other modifications no problem. My stock bootloader have this settings:
mem=41700K@0x0 ispmem=8M@0x28B9000 rmem=15644K@0x30B9000
. Is yours the same?
1600x900 seems to be more reliable with stock bootloader, or there is little difference, I sometimes get failures either way, 1600x900 rarely works with this new bootloader. I am using demo.bin from comment further up in this thread, which someone packaged the drivers in to. I am also using the the additional replacement drivers from this comment Are you using those? I have a second cam that is untouched as yet, I think I will flash normal demo.bin and firmware_mod on that and see if it behaves different.
I am using demo.bin from comment further up in this thread, which someone packaged the drivers in to. I am also using the the additional replacement drivers from this comment Are you using those?
I use normal demo.bin and drivers.zip I put on sd card manually.
The demo.bin from this thread is I think the normal demo.bin but with the drivers.zip from this thread packaged into it. run.sh loads all drivers from the sdcard anyway, so it only makes a difference if you boot without sdcard I guess. I have built my own demo.bin based on the firmware that my came with with my cams that arrived a few days ago 5.6.2.77. The drivers.bin from that firmware contain exactly the same files as drivers.zip from this thread. The firmware_original folder from git hub has 5.6.2.43 and 5.6.2.182, so both different to the firmware my cams were delivered with. I am currently thinking that the new bootloader is most stable when using the original memory settings kernel command line, it behaves similar to stock bootloader in terms of resolution capabilities but should benefit from a slightly higher clock speed, if that is being reported correctly, and it doesn't result in overheating or stability issues. Pressing on with Home Assistant config now, I am going to leave my 1st cam running new bootloader and the 2nd one original bootloader, set them up with the same video and audio settings and see if I notice any differences in performance or reliability.
@spattinson,
Thanks for sharing what you found. I sort of assumed as much, but you confirmed it. Like you, I am also moving on, but in my case to OpenHAB integration.
I never could seem to dump any partitions in the recommended way (using dd). If I stopped uboot and booted instead to a root shell using this method it seemed not to mount the partitions, and I could not seem to find them anywhere, either (although, they must be somewhere). On the other hand, if I let it boot into stock kernel and filesystem, it does not seem to mount the sd card anywhere, and so I have no where to save the files. Because no one with more knowledge replied to help, and we have a working alternative (and I have limited time, like everyone else) I am moving on with my one camera.
I have left the other one on stock with headers soldered in case anyone wants to try and continue development. But for now, personally I need to get on with implementing integration into my overall HA solution (OpenHAB).
I am more than willing to continue contributing later, if anyone is interested, and I have a willing collaborator. I will try and leave my other Xiofang 1S on stock as long as possible in order to keep this door open. Thanks again to all the developers for their work.
Edit: I decided to create/idle in #xiaomi-dafang-hacks on Freenode, if anyone wants to collaborate, without polluting the thread so much.
@jmtatsch:
In the meantime (until we find a way to automagically discover T20 vs T20L), perhaps we should package and list the working driver demo.bin as a separate item in the table at https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks/blob/master/hacks/install_cfw.md ? Or are we waiting for more stability reports (which several of us in this thread should be capable of providing)?
I dump my firmware using the serial console normal boot mode, but its difficult when you cant see what you are typing with all the messages scrolling past, you can type up the commands in an editor and paste them in. I just have a plug with pins that I just rest in the serial holes, so I dont have to solder a header. works fine. I have just realised that the bootloader version displayed in the webserver, which is the same as md5sum /dev/mtd0 is NOT the same as running md5sum on bootloader that are downloaded from here due to padding, ie the bootloader is smaller than the partition:
[root@DAFANG:sdcard]# hd /dev/mtd0 | tail -4
00039920 e0 1b 13 80 03 00 00 00 e4 1b 13 80 03 00 00 00 |................|
00039930 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00040000
[root@DAFANG:sdcard]# hd xiaofang1s_64mb_v2.bin | tail -4
00039920 e0 1b 13 80 03 00 00 00 e4 1b 13 80 03 00 00 00 |................|
00039930 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
000399d0
not the offsets on the left. That explains why I was puzzled yesterday
I just have a plug with pins that I just rest in the serial holes, so I dont have to solder a header.
I can't make up my mind whether that is reckless, or genius. :D
I dump my firmware using the serial console normal boot mode
Where do you dump them to? As I recall, the filesystem was mounted read-only, and the SD card was not mounted at all (when I tried doing it that way).
SD should be mounted with the original fw. If not why not mount is yourself?
¯\_(ツ)_/¯
I only gave it a try for a few minutes, as it seemed we already have copies of this version of firmware. So I got on with other things at the time that were more pressing.
However I will try again later, as I would like to have copies here for myself (plus learning how to do it).
Also, by now I have got it sending the RTSP stream to Motion running on an ODROID-XU4. After spending last night tweaking that a bit, I've got it fairly reliably detecting motion, and then saving those videos to a Syncthing folder, which in turn syncs them to other devices. Next step will be to tie some sort of notification / presence detection into OpenHAB, but I'm getting off topic. :)
Point being, now that I have fun and exciting things actually working, I would kind of like to get my other Xiaofang (which is still on stock) flashed so I can add a second camera to my (now working) setup. So, thanks for pointers. :)
Is it possible to have a summary of what is possible today with T20L xiaofang ? I just received mine, how can I easily and securely hack it to have stable rtsp server ? Can I only use a sdcard to hack it or it needs more stuff ?
Is it possible to have a summary of what is possible today with T20L xiaofang ? I just received mine, how can I easily and securely hack it to have stable rtsp server ? Can I only use a sdcard to hack it or it needs more stuff ?
Install cfw from git and drivers.zip from this thread to your sd card. 720p stream is working great.
Could you confirm the steps are : 1 - install the microSD bootloader, i can use the standard : Xiaomi XiaoFang T20 cfw-1.0.bin renamed to demo.bin 2 - install firmware_mod on a sdcard and replace de drivers with one from this topic and modify the wpa_supplicant.conf from config folder
Could you confirm the steps [...]
I think that way works also? The way I did it was to use the demo.bin.zip from this post which apparently contains the needed drivers. But I think others have done it the way you describe also.
@jmtatsch Again I request to add another option to download menu listing T20L separately. Or are we still trying to figure out a reliable way in software to identify them?
We should probably discuss options in the case that such a way cannot be found. Perhaps we need to figure out approximate date of the changeover, for people to know they might need T20L version instead?
It is not clear for me if it is needed to use the demo.bin.zip from this post as the new drivers must just be replaced in the firmware_mod part ? Is there any advantage to use the demo.bin from this post and not the xiaofang cfw-1.0.bin original from the git ?
I see also some info in this topic to modify uEnv.bootfromnand.txt, is it needed ?
@Juumm You can do either way - both will work. Modifying uEnv only needed if you want to get 1080p stream working. But in order to do that you need to flash custom u-boot first.
If you use new open source uboot loader that support uEnv.txt you seem to lose ability to flash using button hold and demo.bin method. That was my experience anyway, bootloader does not check gpio. Worth noting if you want to try out different firmware. I guess there is a way of flashing from bootloader prompt instead i dont know if this is documented anywhere. I am currently using original bootloader and demo.bin made from wyze rtsp firmware because i wanted to see if i could try out their rtsp, i couldnt find an easy way to do that because my hardware is not wyze branded, it looks like their rtsp is bundled in the iCamera binary that does all the other stuff too. I have found that this firmware combo with my original kernel drivers is most stable so far. Been running for a day now with no restarts of anything required at 1280x720.
The demo.bin from this thread contains drivers for t20l BUT run.sh loads all kernel drivers from sdcard. The only purpose is if you boot without sdcard without run.sh and want to use mi home app then you will load drivers from internal mtd flash.
I think that way works also? The way I did it was to use the demo.bin.zip from this post which apparently contains the needed drivers. But I think others have done it the way you describe also.
Ok I am at a loss. I am able to flash my 1S (T20L, presumably) and it boots but doesn't see wlan0 so no joy on wifi. I am NOT able to flash the demo.bin referenced above, using the same card and process, and it does the usual thing of creating a timelapse folder. Thoughts?
@claud9999 You did not put drivers on your SD card - thats why you have no wifi on T20L.
@claud9999 You did not put drivers on your SD card - thats why you have no wifi on T20L.
Success! So my process was to flash the "stock" cfw-1.3.bin, copy firmware_mod to the SD card, then copy over the new drivers to the "driver" folder on the SD card.
Video resolution working maximum in 1600x900
1600x900 resolution - stock demo.bin + firmward mod with drivers from this thread Running fine during two days but today camera is no more accessible
Is it stable for weeks for you ? How to have stable 24/7 working camera ?
I am using with home assistant and I think the frontend in ha is not without issues, that is vlc works when the stream in home assistant doesnt, but if you retry in home assistant it mostly works the second time. Using the camera.record service in home assistant works 100% though. That is what is important to me. You can always restart the rtsp server from home assistant if it seems to be unresponsive, that can be automated. I have wyze firmware with my original kernel modules currently. I think i will try to make the best out of what it is, ie bouncing the rtsp service when necessary.
I got a new Xiaofang that I think is T20L
I put the cfw-1.3.bin and tried also the cfw-1.0.bin as demo.bin but when starting the camera with setup pressed, it says "dendai enji" (google translated to: waiting for connection) what I do wrong?
@ageorgios Did you format your SD card with 512MB partition?
No I will try that, on a dafang it worked without limiting the partition, thank you
After all, it does not seem to be stable. Even in default (1280x720) my Xiaofang is up for around 20 hours maximum, after the Xiaofang is not reacchable (web/ssh/ping)
Is there something to do to have at least a Xiaofang stable working for a long period ?
I try to enable swap 512 and also to disable log but around 20h is the max my Xiaofang T20L can be alive. If someone have an idea ?
@Juumm disabling log cant help solving your problem. You should enable and read it to find out what happening with your camera. Best way to diagnose it is opening up the case, hooking UART cable and leaving it on your bench until it dies. Then the last messages on the console will give you a clue whats going on with it. It could be a wifi card issue, could be the CPU itself is overheating... could be anything.
I'm thinking there's at least three revs of the "1S". I have 5 of them and so far the following 3 have the behavior below:
1S, MAC 44:23:7C:4C:90:B7 -- runs with "master" Dafang firmware_mod, no drivers.zip needed.
1S, MAC 34:CE:00:B2:31:76 -- flashed fine with "cfw_1.3.bin". Runs with drivers.zip from this ticket (stock firmware_mod results in no wlan0 device.) Note the different QR code pattern and MAC address font.
1S, MAC 78:11:DC:7B:AB:03 -- flashed fine with "cfw_1.3.bin". Boots but reports no wlan0 in startup.log, for either "master" or with modified drivers.zip. Same style QR code as the top one. I did create the wpa_supplicant.conf file, and I've tried just swapping the SD cards the third won't boot of either of the first two's cards. Anybody have a link for instructions on how to connect to the UART? I can also take pics of the board if folks are interested.
Pics of the stickers below:
@claud9999 1S with MAC 78 is the only one with T20L processor which is discussed in this thread.
BTW, for the Xiaofang you should use cfw-1.0.bin, not cfw_1.3.bin.
I see that this issue is closed. Does this mean that the T20L is officially supported and runs fine now?
Yes I would have the same questions as @aminhusni?
I have 1S with MAC starting with 78, yesterday used the hack as it's described in install_cfw.md and everything works ok so far
If the new T20L version is working, maybe someone should update README.md to reflect this.
Hi As all new Xiaomi Xiaofang 1S have T20L chip that does not work well with current dafang hack, is it planned soon to support officially new Xiaomi Xiaofang 1S T20L ?