Thought I'd start a new thread on this. Kind of carrying on from BT HomeHub stuck in CFG04 mode after installation but with a few more details/questions and a different scenario.
So, I got a second hub and I've managed to brick it without installing LEDE! Before I go any further with details here is what I have assumed is happening when you follow the instructions.
- boot with boot_sel2 low - force a boot of an ascii image
- cat lede-lantiq-bthomehubv5a_ram-u-boot.asc > /dev/ttyUSB0 - send an ascii image to the lantiq SOC and boot it
- tftpboot 0x81000000 lede-lantiq-xrx200-BTHOMEHUBV5A-installimage.bin - download a bigger more fully featured install image to RAM i.e. this isn't permanent
- bootm 0x81000000 - boot that image. Again, nothing permanent
This is where I have got to. I have run the nanddump to backup the device. I have also done this with openwrt images (openwrt-lantiq-bthomehubv5a_ram-u-boot.asc and openwrt-lantiq-xrx200-BTHOMEHUBV5A-install-uImage-initramfs). I note the difference between openwrt (/dev/mtd6) and LEDE (/dev/mtd4).
I took two backups with each (i.e. went through the process 4 times - i.e. serial boot+tftpboot) as my restore to BT firmware on the first hub failed so I wanted to be sure this had worked.
Note: I never once ran prepare.
I thought at this point I had done nothing to modify my hub (other than attach the serial wires). The images were in RAm an the BT firmware was still in untouched NAND storage. Is this (or should this be) the case? However, I find that my hub is now stuck in serial boot. If my assumptions above are correct, then I can only assume that I have somehow shorted the boot_sel2 line to something it didn't like (and now holds it permanently low) OR the hardware defaults to serial boot after being serial booted X number of times.
Interested to know if my thoughts on what was happening when following the instructions were correct? Also, any great ideas. If I get another I may just do it all in one go - Fortune favours the brave and all that.
Throwing caution to the wind I just booted it up and ran prepare and sysupgrade.
It's bricked. Perhaps more so now.
I have a standard USB to serial converter straight to the connections. Could voltages be breaking it?
Maybe, was the adaptor stepping down to 3v?
running at 5v could burn out the port.
Hmmm. Maybe. However, it still functions as a serial port i.e. I can boot with the .asc image.
Have acquired a 3.3/5v serial adapter off Ebay so once I find another unit I will try again.
Any idea if my understanding of what I'm doing (i.e. actions that I believe should be non-permanent are correct? Would love to read a guide about this hardware and how it works.
Right. Good News!
I've managed to flash HH5A number 3. Worked perfectly.
My conclusion is that my USB to RS232 was damaging the chip such that it was always was in serial mode afterwards (I've booted brick number 2 via ascii and then watched it boot LEDE so the flashing was all okay).
Using a USB to TTL serial was the answer (hindsight makes this obvious).
This the item (and seller) that worked for me http://www.ebay.co.uk/itm/USB-2-0-to-Serial-TTL-with-Dual-3-3V-and-5V-Output-and-Leads-suits-RPI-Arduino-/111328729888.
My next hassles are with routing and getting LUCI installed without using the WAN interface but that's for another day.
P.S. Flashed using the recent RC2
Not sure what you mean? RC2 has LUCI already installed.
Oh damn, you were using a USB to 12v PC serial port thing? Surprised your routers didn't let out the magic smoke
Well, 2 mins after my last post I rebooted and redid the same routing commands and opkg update and opkg install luci worked fine. The latter was really quick so I guess luci was installed :).
As for magic smoke, I didn't see any. The serial port as worked fine all along. Just sticks in serial boot. Oh well.
Returning to the unit tonight I've found another funny but I'll see what else has been posted before going much further. Put simply, the unit kernel panics during power up if the fourth ethernet port is active. Nothing plugged in and it starts up fine.