Are you using a squashfs image? The initrd image doesn't save anything to flash.
Topic: Files and install instructions for HooToo HT-TM02 and HT-TM04(RT5350)
The content of this topic has been archived between 29 Mar 2018 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.
thanks for the reply. Yes, I'm using squashfs. I think maybe my image is too big. Going to try reducing it.
For the time being, I'm using the latest trunk image, but I'm not having any luck w/ the USB.
I installed kmod-usb-serial, kmod-usb-serial-ftdi and kmod-usb-serial-cp210x.
Yet, when I plug in a FTDI or CP2101 USB->serial adapter, I don't get any /dev/ttyUSB* devices.
When I do "logread | grep -i usb" it doesn't show that the devices are attached.
Is there something else that I need to do to enable the USB support? TIA!
Check logs and see if the jffs is being created during the first boot.
root@OpenWrt:/# dmesg |grep jffs
[ 0.000000] Kernel command line: console=ttyS0,57600 rootfstype=squashfs,jffs2
[ 0.320000] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[ 31.620000] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
[ 31.660000] jffs2_build_filesystem(): unlocking the mtd device... done.
[ 31.660000] jffs2_build_filesystem(): erasing all blocks after the end marker...
[ 79.480000] jffs2: notice: (1016) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
root@OpenWrt:/# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 3328 1300 2028 39% /
/dev/root 3584 3584 0 100% /rom
tmpfs 14664 416 14248 3% /tmp
tmpfs 14664 44 14620 0% /tmp/root
tmpfs 512 0 512 0% /dev
/dev/mtdblock5 3328 1300 2028 39% /overlay
overlayfs:/overlay 3328 1300 2028 39% /
You need kmod-usb-ohci to drive USB1 (low speed or full speed) devices plugged directly to the port. If you only have kmod-usb2, it will work only with high speed devices plugged directly, or any device if you connect it through an external USB2 hub.
(Last edited by mk24 on 27 Dec 2014, 21:36)
Check logs and see if the jffs is being created during the first boot.
root@OpenWrt:/# dmesg |grep jffs [ 0.000000] Kernel command line: console=ttyS0,57600 rootfstype=squashfs,jffs2 [ 0.320000] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. [ 31.620000] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0 [ 31.660000] jffs2_build_filesystem(): unlocking the mtd device... done. [ 31.660000] jffs2_build_filesystem(): erasing all blocks after the end marker... [ 79.480000] jffs2: notice: (1016) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
You need kmod-usb-ohci to drive USB1 (low speed or full speed) devices plugged directly to the port. If you only have kmod-usb2, it will work only with high speed devices plugged directly, or any device if you connect it through an external USB2 hub.
Strange, I reinstalled my self-built image a few times, and now it can save files OK. The first time, I was getting an error that I can't remember anymore. Now, my jffs2 messages are like yours above.
Installing kmod-usb-ohci fixed my problem w/ the USB 1.x devices. Thanks!
Wingspinner:
You mentioned a while back that you were considering upgrading the flash to 16mb. Did you succeed in doing that?
Thanks for all the work on this. I installed OpenWRT today and it was a breeze. Any idea what it would take to get the mode switch working? I would love to install TOR on this and use the switch to turn TOR on and off.
Wingspinner:
You mentioned a while back that you were considering upgrading the flash to 16mb. Did you succeed in doing that?
Holidays put a stop to my work and I haven't got back to things yet. I did upgrade to 16mb and it works fine. Requires some new patches which I hope to publish soon. Thing is, what's really needed is more RAM (at least for my apps). Unfortunately, the address pin needed isn't routed as far as I can tell so it's going to be rather difficult to expand the RAM.
One other note that may be of interest to those who have bricked your units is I've found that I can flawlessly program the flash in-circuit (i.e. without removing the flash chip). Very convenient. I use flashrom, the TIAO Tumpa (USB Multi-Protocol Adapter), and one of these: http://www.ebay.com/itm/SOIC8-SOP8-Flas … 20eabb4e3f
I've found the in-circuit method to be much quicker and easier than TFTP.
Cheers...
Thanks for all the work on this. I installed OpenWRT today and it was a breeze. Any idea what it would take to get the mode switch working? I would love to install TOR on this and use the switch to turn TOR on and off.
The mode switch requires a simple patch to the device tree which I might get around to submitting. I'll need to go back to my notes to find what I/O pin it's on. Then you'd need some software to read it and take the action you wish. It's a "nice-to-have" which is why I never bothered with it but it's on my list.
Thank you, @wingspinner, for the great work! I love the pain-free install process via the factory image. Sweet!
I just ran into a little snag during the configuration (I've been using LuCI, but I do know my way around the shell a bit as well):
- I set the green LED to show LAN activity, set the IP address of the LAN interface to static and turned off DHCP for the interface. Reboot. Everything still works great and the device is reachable via the new IP as expected.
- I disabled the WiFi interface and unchecked "bring up interface on boot" for it. Reboot. And the device doesn't answer on the static IP on the LAN interface any more!?!?
Symptoms:
- Both LEDs come on and turn off during the initial boot as usual.
- The blue WiFi LED stays off (as expected).
- The green LAN LED comes on and even blinks a bit (probably other traffic on the network), which looks to me like the device is still booting to the point where it brings up the LAN fully.
Is there some step in the boot process after the LAN interface is turned on that fails if the WiFi interface is missing? I noticed a br-0 interface in the configuration, but didn't look at it any closer. Is this bridge trying to span the WiFi as well and then fails to initialize (and thus set the IP) if WiFi is unavailable? Is there a chance that the LAN interface is brought up in some default configuration instead that I might be able to use to fix things? Or will I have to crack the device open and hook into the serial interface?
@wingspinner, how difficult would it be to get the failsafe mode working in your patch? Is this something I could help with if you give me some quick pointers (I have quite a bit of coding experience, albeit not too much embedded stuff) or would it be more involved? I (and probably others, too) would feel a lot safer playing around with the configuration if I could always just do a "factory reset" (firstboot) easily if something gets screwed up.
Thanks again for all your work! Most appreciated!
Can't say exactly what is causing your issue but the default configuration is with WiFi as WAN and Ethernet as LAN and it does work if you turn off the WiFi. My guess is somewhere along the line you've modified the network file causing the problem or perhaps the route isn't set correctly.
WRT failsafe mode, it's my understanding that it's enabled in the trunk. I don't use it so I don't know how/if it works.
I'm comparing it to an Encore ENHWI-3GN3 which is some sort of Senao generic board. That one is running BB 14.07, a custom build just so I could fit what I needed into the 4MB flash.
......
The Senao clocks the CPU at 320 MHz and the HooToo at 360. Notice the much higher BogoMIPS on the HooToo which is not merely proportional to the higher clock.
I'm interested in trying to overclock the HooToo since it seems to not have quite enough CPU to run baresip, which is what I bought it for.
Complier difference? Overclocking isn't going to get you there...
Has anyone else noticed USB not working with the trunk image (as of 12/17/14) ? I had to install kmod-usb2 which was not in the trunk build. Also kmod-usb-dwc2 doesn't seem to do anything on this hardware and can be left out. In order to connect a USB1 speed device directly to the USB port, kmod-usb-ohci must be installed. USB1 devices can be used through an external USB2 hub with kmod-usb2.
The unit I have has a v3 version of the 5350 chip. Apparently there are some changes in the USB section from the v2 chip.
All the correct modules are installed as default as I recall so I'm not sure why additional modules would be needed. I've used the usb port with storage devices, serial to usb converters, as well as usb cams and it's working fine. When I get a chance I'll look at the trunk and see if things got changed somehow.
Welcome back, wingspinner.
WRT failsafe mode, it's my understanding that it's enabled in the trunk. I don't use it so I don't know how/if it works.
Failsafe mode works w/ the trunk image. I've gotten into it via the serial console. I *think* it also works w/ the reset button as well, but I can't access mine right now to verify if my memory is correct on that, because it's installed in my garage at the moment.
One thing to remember....
The "factory" image is based on an older snapshot of trunk. There is nothing wrong with it - it works fine for everything that I'm doing. However, if you want to be running the latest greatest trunk revision make sure you do a system upgrade using the trunk image after installing the factory image. The instructions have been updated to reflect this.
Cheers,
Ron (Wingspinner)
mk24 wrote:Has anyone else noticed USB not working with the trunk image (as of 12/17/14) ? I had to install kmod-usb2 which was not in the trunk build. Also kmod-usb-dwc2 doesn't seem to do anything on this hardware and can be left out. In order to connect a USB1 speed device directly to the USB port, kmod-usb-ohci must be installed. USB1 devices can be used through an external USB2 hub with kmod-usb2.
The unit I have has a v3 version of the 5350 chip. Apparently there are some changes in the USB section from the v2 chip.
All the correct modules are installed as default as I recall so I'm not sure why additional modules would be needed. I've used the usb port with storage devices, serial to usb converters, as well as usb cams and it's working fine. When I get a chance I'll look at the trunk and see if things got changed somehow.
Checking the latest trunk build it appears the OpenWRT powers that be arbitrarily removed all the default packages I had defined for the default build. My intent was to save users time by selecting all the correct kernel modules that made a complete system (i.e. support for all the built-in hardware). What's there now won't do much for you. You can add them back in at run-time but it's not as efficient in my opinion. Here is the original configuration for reference:
define Profile/HT-TM02
NAME:=HOOTOO HT-TM02
PACKAGES:=\
wpad-mini \
kmod-ledtrig-netdev kmod-ledtrig-timer kmod-leds-gpio kmod-ledtrig-default-on \
kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-usb-net usbutils \
kmod-scsi-core kmod-scsi-generic kmod-fs-ext4 \
kmod-usb-storage kmod-usb-storage-extras block-mount \
kmod-usb-serial kmod-usb-serial-ftdi kmod-gpio-button-hotplug \
kmod-nls-cp437 kmod-nls-iso8859-1 kmod-nls-utf8 luci luci-mod-admin-full \
kmod-app-samba luci-theme-openwrt luci-proto-relay relayd nano \
fstools
endef
Welcome back, wingspinner.
Thank you. Happy New Year!
jacknweems wrote:Thanks for all the work on this. I installed OpenWRT today and it was a breeze. Any idea what it would take to get the mode switch working? I would love to install TOR on this and use the switch to turn TOR on and off.
The mode switch requires a simple patch to the device tree which I might get around to submitting. I'll need to go back to my notes to find what I/O pin it's on. Then you'd need some software to read it and take the action you wish. It's a "nice-to-have" which is why I never bothered with it but it's on my list.
If you get a chance to submit that patch I would be much appreciative.
Well this is embarrising. I flat forgot my password. I installed wingspinner's origional image but haven't run any upgrades. What options do I have for getting back in?
Well this is embarrising. I flat forgot my password. I installed wingspinner's origional image but haven't run any upgrades. What options do I have for getting back in?
Unfortunately I didn't include "failsafe" mode in that image. Failsafe appeared to be causing some odd behavior while I was debugging plus it takes some flash space so I removed it early on and never bothered to mess with it. The trunk upgrade version does include failsafe though (but that doesn't help you). There are a few options though that come to mind.
1. Upgrade with an "upgrade" image - either one of mine or from the trunk - using TFTP. The HT-TM02 ip address will be 10.10.10.123 and the server will need to be 10.10.10.3 .
2. Connect the serial - no password required. By far the easiest (at least for me since I have all the stuff to do it in 5 minutes)
3. I can't remember if the original image has the busybox ftp or not but if it does, you may be able to get in though that and use it to modify the passwd file.
4. Otherwise it's standard linux "lost password" stuff you can google.
For many people it's probably a good idea to upgrade first thing to the trunk image after booting my initial factory image so you'll have failsafe capability.
wingspinner wrote:jacknweems wrote:Thanks for all the work on this. I installed OpenWRT today and it was a breeze. Any idea what it would take to get the mode switch working? I would love to install TOR on this and use the switch to turn TOR on and off.
The mode switch requires a simple patch to the device tree which I might get around to submitting. I'll need to go back to my notes to find what I/O pin it's on. Then you'd need some software to read it and take the action you wish. It's a "nice-to-have" which is why I never bothered with it but it's on my list.
If you get a chance to submit that patch I would be much appreciative.
Ok, my memory failed me. I checked and I did include support for the mode switch in the DTS. So it is in there but how it get's used is dependent on what you want it to do. My guess is you want to be able to switch from adapter mode to AP mode. The openwrt folks have provided a mechanism that allows one to customize any switch or button however one wishes but it will take a bit of work on your part. A good place to start is here: http://wiki.openwrt.org/doc/howto/hardware.button
Cheers,
are the tm02 and tm01 similar enough that this openwrt image could be used on my tm01?
i am willing to experiment, but if others have already learned success or brick on the tm01 then i'd like to know.
thanks!
are the tm02 and tm01 similar enough that this openwrt image could be used on my tm01?
i am willing to experiment, but if others have already learned success or brick on the tm01 then i'd like to know.
thanks!
I'm not familiar with the TM01 at all and there may be various differences such as which gpio pins are connected to what switches/LED's or other devices via I2C, etc. That would need to be researched and confirmed. If it's a basic Rt5350 SOC like the TM02 it should work otherwise. If you plan to use my "factory" image the tm01 would need to be able to accept the same firmware upgrade image format as the TM02. If the HooToo tm01 uses the same firmware upgrade image format there is still a good chance that it checks to make sure the image is for the tm02 before loading it. In that case it would fail and the "factory" image would need to be modified so that it specifies tm01 in the image header and cksum recalculated and updated. If you can verify that there is no additional hardware on the various peripheral I/O's and the "factory" firmware image formate then there is a good chance it would work. Since none of this has been checked out it's an "experiment".
I appreciate how helpfull everyone has been on this thread. Work has been crazy so I'm just now getting back to this. I think uploading an image via TFTP is going to be my only way back in. I have a TFTP server set up but I'm not clear on what file I need upload.
Before continuing, I'd just like to add my thanks to Wingspinner and others who have contributed to this body of work - long may it continue.
My issue is as follows:
I've installed Wingspinner's 'factory image' on the HooToo TM2 and can successfully use the device to access a WiFi network via the cabled lan interface. However, my objective, is to use the TM2 as a OpenVPN client where the WAN is the cabled interface and the LAN is wireless. I've successfully configured OpenVPN (BB) on a TP-Link MR3020 in this manner and it functions very well - The only downside, is that it was necessary to add external USB storage to the MR3020, as it only has 4Mb of flash, which is too small to install the OPenVPN packages - the device is also approx twice the physical size of the TM2.
I've now acquired a HooToo TM2 and am trying to configure it in the same way as the MR3020.
By following the same configuration process, I am able to access the TM2 wifi interface on the lan, but the cabled WAN interface (in dhcp client mode) does not seem to be picking up an IP address from the external router. So... My question is, are there any additional patches or packages (other than those ultimately required to run OpenVPN) that need to be applied to the "openwrt-ramips-rt305x-ht-tm02-squashfs-factory-r42649.bin" factory build, in order to get the basic networking aspects of my desired configuration working properly?
Thanks in advance for any insights or contributions...
TM
My question is, are there any additional patches or packages (other than those ultimately required to run OpenVPN) that need to be applied to the "openwrt-ramips-rt305x-ht-tm02-squashfs-factory-r42649.bin" factory build, in order to get the basic networking aspects of my desired configuration working properly?
Thanks in advance for any insights or contributions...
TM
No additional patches needed. You'll likely need to reconfigure the network, wireless, and firewall configuration files though to match what is required for openVPN. The default configuration is as a "routed bridge" (although bridge is an incorrect term in this instance however that's what the OpenWRT wiki calls it) with the wifi set as wan and the ethernet set as the local network.