OpenWrt Forum Archive

Topic: OpenWRT on BT Home Hub 2A

The content of this topic has been archived between 31 Mar 2018 and 16 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

gomme600 wrote:

Anyway I have done a backup of the same CUSTOM.BIN, here is the file: http://www.mediafire.com/download/qad3j … BACKUP.BIN

So when I compare that to 906cebfc82efc881ea16f0f3501ba82b, it's almost identical except for six places.  In every one of them, you have 0xffff where I have something else.  (At least this tells you it's roughly flashing the correct file!  Also, maybe yours takes less time than mine because /nodma slows my flashing down.)  Possibilities:

  • there are glitches during your flashing (maybe try slowing it down with /delay:20 ? maybe fight harder to get /nodma working, just for the side-effect of slow-but-sure flashing?)

  • you're flashing just fine, but you're somehow getting errors reading back; in this case, reading multiple times seems likely to give different results; try doing it a bunch of times and seeing whether the md5sum of the backup varies

  • the flash on your unit is faulty and is incapable of writing data at those six locations; once you've done your best to eliminate write errors and read errors, you could test for this by writing a file of plain zeroes and seeing whether the read comes back with  contains anything else

gomme600 wrote:

I get nothing on the serial port still. This all seems very strange to me.

The first thing CFE does is decompress the bootloader.  If the CPU is really seeing those 0xffff and if they lie in the compressed data, CFE would either detect that during decompression and die, or decompress some garbage and try to run it (and die).  Some bootloaders at least announce what they're doing before they try it, but from the look of the logs on the wiki it seems this CFE doesn't, so you may just see nothing.  But we should also consider the possibility that your serial port connection is dodgy, unless you ruled that out earlier?

gomme600 wrote:

It is 128KB instead of 62KB, again I don't understand?

That's because we're using /length:20000.  That's bigger than it needs to be.  It doesn't do any harm.

zx82 wrote:
gomme600 wrote:

Anyway I have done a backup of the same CUSTOM.BIN, here is the file: http://www.mediafire.com/download/qad3j … BACKUP.BIN

So when I compare that to 906cebfc82efc881ea16f0f3501ba82b, it's almost identical except for six places.  In every one of them, you have 0xffff where I have something else.  (At least this tells you it's roughly flashing the correct file!  Also, maybe yours takes less time than mine because /nodma slows my flashing down.)  Possibilities:

  • there are glitches during your flashing (maybe try slowing it down with /delay:20 ? maybe fight harder to get /nodma working, just for the side-effect of slow-but-sure flashing?)

  • you're flashing just fine, but you're somehow getting errors reading back; in this case, reading multiple times seems likely to give different results; try doing it a bunch of times and seeing whether the md5sum of the backup varies

  • the flash on your unit is faulty and is incapable of writing data at those six locations; once you've done your best to eliminate write errors and read errors, you could test for this by writing a file of plain zeroes and seeing whether the read comes back with  contains anything else

gomme600 wrote:

I get nothing on the serial port still. This all seems very strange to me.

The first thing CFE does is decompress the bootloader.  If the CPU is really seeing those 0xffff and if they lie in the compressed data, CFE would either detect that during decompression and die, or decompress some garbage and try to run it (and die).  Some bootloaders at least announce what they're doing before they try it, but from the look of the logs on the wiki it seems this CFE doesn't, so you may just see nothing.  But we should also consider the possibility that your serial port connection is dodgy, unless you ruled that out earlier?

gomme600 wrote:

It is 128KB instead of 62KB, again I don't understand?

That's because we're using /length:20000.  That's bigger than it needs to be.  It doesn't do any harm.

Hi again. This is the file I get with /delay:20. It's much better but not perfect (Increasing the delay gives the same results): http://www.mediafire.com/download/2402k … 323_142008

Still can't get it to boot. I will try playing around with it a bit more but I don't really know where to go from here then... Your suggestion of writing zeros to test sounds good but I don't know too much about hex editors, should I just fill a .bin file with zeros in the editor?

Thanks for the help!

EDIT:

Empty file came back good as far as I can see: http://www.mediafire.com/download/m21nt … 323_145030

I suppose this suggestes that my flash chip is fine then?

EDIT2:

It appears that the new file with delay:20 is actually the same, my hex editor said is wasen't but it's beacause of it missing 4 zeros at the end maybe? Anyway I think it's the same. So it appears to be flashing correctly, what am I missing? Any buttons I should be pressing? I have tried the "find handset" button so far.

(Last edited by gomme600 on 23 Mar 2016, 16:04)

gomme600 wrote:

Hi again. This is the file I get with /delay:20. [...] Anyway I think it's the same. So it appears to be flashing correctly,

I agree, matches now.

gomme600 wrote:

what am I missing? Any buttons I should be pressing? I have tried the "find handset" button so far.

If you have working serial access, buttons aren't strictly necessary and you'd certainly see serial output without having to do anything at all.  What should happen is that CFE should (loudly) fail to detect any valid firmware, then sit at a prompt waiting for input while offering HTTP and/or TFTP access.  Likely possibilities:

  • It's flashed OK, but your serial access is faulty.  When you established serial access, did you test it?  As in, did you watch the stock firmware produce output?  Input needs to work too; did you ever interact with the stock bootloader or a login prompt on the serial console?  Check continuity between your TX/RX pins and the corresponding solder bridges you added nearby, and check ground against something convenient nearby (maybe the big metal can over the WiFi).  Check that you have TX and RX the right way around (you could just use a multimeter on the pins while sending something using your serial software, and see if the voltage changes).  But even if it's working and you just can't see it owing to serial malfunction, you should at least be able to ping it at 192.168.1.1 by now.

  • It's flashed OK, but the image is somehow incompatible with the unit.  There's a (slim) chance my CFE doesn't work on Spansion units, so now that you're more confident that flashing is intact, maybe it's worth trying danitool's original CFE again.  I think you need the swapped version I posted above (md5sum 7f7dcd973ada548d1ebcd9cbcaec17c8), but...

  • It's flashed OK, but somehow I'm totally wrong about the byteswapping thing.  If that's the case, danitool's original Spansion-only image or my unswapped ST-compatible version would work (now that flashing issues seem to be fixed).

  • It's flashed OK, but something else on the unit is hosed, or the CPU is being held in reset.  Maybe you could tell by getting OpenOCD attached to it, but I've not yet had to do that on a unit and can't help.

zx82 wrote:
gomme600 wrote:

Hi again. This is the file I get with /delay:20. [...] Anyway I think it's the same. So it appears to be flashing correctly,

I agree, matches now.

gomme600 wrote:

what am I missing? Any buttons I should be pressing? I have tried the "find handset" button so far.

If you have working serial access, buttons aren't strictly necessary and you'd certainly see serial output without having to do anything at all.  What should happen is that CFE should (loudly) fail to detect any valid firmware, then sit at a prompt waiting for input while offering HTTP and/or TFTP access.  Likely possibilities:

  • It's flashed OK, but your serial access is faulty.  When you established serial access, did you test it?  As in, did you watch the stock firmware produce output?  Input needs to work too; did you ever interact with the stock bootloader or a login prompt on the serial console?  Check continuity between your TX/RX pins and the corresponding solder bridges you added nearby, and check ground against something convenient nearby (maybe the big metal can over the WiFi).  Check that you have TX and RX the right way around (you could just use a multimeter on the pins while sending something using your serial software, and see if the voltage changes).  But even if it's working and you just can't see it owing to serial malfunction, you should at least be able to ping it at 192.168.1.1 by now.

  • It's flashed OK, but the image is somehow incompatible with the unit.  There's a (slim) chance my CFE doesn't work on Spansion units, so now that you're more confident that flashing is intact, maybe it's worth trying danitool's original CFE again.  I think you need the swapped version I posted above (md5sum 7f7dcd973ada548d1ebcd9cbcaec17c8), but...

  • It's flashed OK, but somehow I'm totally wrong about the byteswapping thing.  If that's the case, danitool's original Spansion-only image or my unswapped ST-compatible version would work (now that flashing issues seem to be fixed).

  • It's flashed OK, but something else on the unit is hosed, or the CPU is being held in reset.  Maybe you could tell by getting OpenOCD attached to it, but I've not yet had to do that on a unit and can't help.

Unfortunately I only tried connecting serial after flashing CFE so I have never seen it working. Also, ethernet doesn't work at all, since flashing CFE the activity lights on my computer don't even flash, nothing at all...

I have tried the various images you have provided, I can try more combinations when I have some more time to spare but I don't think I am going to get it to work somehow...
Do you think we can try a wholeflash now? As we know it's flashing correctly we could try a normal and a byteswapped wholeflash (If you have one handy and it doesn't bother you that is).

I would love to try OpenOCD, I tried setting it up when you mentioned it the other day but couldn't get it working, don't really know how to get it to ise the pi's gpio pins! So I would prefer to stay away from it if possible.

Thanks again for the help so far!

Hi, I did the byte swap with an utility that worked for me long time ago with the old hairydairymaid.

No idea if the byte swapping is the same as made by zx82. BTW here you have if you want to test it:

https://drive.google.com/file/d/0B-EMoB … sp=sharing

danitool wrote:

Hi, I did the byte swap with an utility that worked for me long time ago with the old hairydairymaid.

No idea if the byte swapping is the same as made by zx82. BTW here you have if you want to test it:

https://drive.google.com/file/d/0B-EMoB … sp=sharing

Hi, thanks for the file! It's the same as zx82's (same md5sum and checked in a hex editor), tried flashing it anyway and it still doesn't work. I feel like we are running out of options... Do you have any ideas? Anything zx82 might not of thought of?

gomme600 wrote:

Do you think we can try a wholeflash now? As we know it's flashing correctly we could try a normal and a byteswapped wholeflash (If you have one handy and it doesn't bother you that is).

I can make you a full image of a freshly installed unit containing the ST-and-Spansion-compatible CFE and 15.05.  I'll try to sort that out tomorrow.  Although...

gomme600 wrote:

Also, ethernet doesn't work at all, since flashing CFE the activity lights on my computer don't even flash, nothing at all

...if you're not even getting a link heartbeat light and can't ping the unit then it doesn't sound like CFE is ever running, and I don't see that anything will change with the whole-flash image.  (I'll still make it for you though.)

gomme600 wrote:

I only tried connecting serial after flashing CFE so I have never seen it working.

But it passes those continuity tests, right?  And you've checked that TX/RX aren't bridged together or anything?  Sorry to keep going on about the serial access but since it's so useful for debug when working, it seems worth exhausting all possibilities there.

Sorry that this unit is fighting you.  If it won't boot with the whole-flash either, one last thing before OpenOCD might be to try restoring your broken backup and then restoring the stock CFE over the top, hopefully giving you exactly what you started with.  I think I have a copy of the CFE my Spansion unit came with, which I could upload.  But that does sort of assume that your backup doesn't have any 0xffff artefacts from glitchy reads.

(Last edited by zx82 on 25 Mar 2016, 01:01)

zx82 wrote:
gomme600 wrote:

Do you think we can try a wholeflash now? As we know it's flashing correctly we could try a normal and a byteswapped wholeflash (If you have one handy and it doesn't bother you that is).

I can make you a full image of a freshly installed unit containing the ST-and-Spansion-compatible CFE and 15.05.  I'll try to sort that out tomorrow.  Although...

gomme600 wrote:

Also, ethernet doesn't work at all, since flashing CFE the activity lights on my computer don't even flash, nothing at all

...if you're not even getting a link heartbeat light and can't ping the unit then it doesn't sound like CFE is ever running, and I don't see that anything will change with the whole-flash image.  (I'll still make it for you though.)

gomme600 wrote:

I only tried connecting serial after flashing CFE so I have never seen it working.

But it passes those continuity tests, right?  And you've checked that TX/RX aren't bridged together or anything?  Sorry to keep going on about the serial access but since it's so useful for debug when working, it seems worth exhausting all possibilities there.

Sorry that this unit is fighting you.  If it won't boot with the whole-flash either, one last thing before OpenOCD might be to try restoring your broken backup and then restoring the stock CFE over the top, hopefully giving you exactly what you started with.  I think I have a copy of the CFE my Spansion unit came with, which I could upload.  But that does sort of assume that your backup doesn't have any 0xffff artefacts from glitchy reads.

Thanks for the wholeflash. I think anything is worth trying at the moment. Serial is weird, RX an TX on the unit both mesure 3.3 volts. I would have thought that RX would be 0v... I have bridged the two resistor pads under the board like shown on the wiki. I have an oscilloscope aswell but that didn't show anything from the unit. It did from the pc though. Laslty we agree that the unit's RX (marked on the wiki photo) goes to my serial adapters TX yes?

If the wholeflash doesn't work I would like to try your last suggestion, trying stock firmware is always a good test. I can also try using a pc serial port if this all doesn't work, it will be a bit of a pain but it will prove that the pi isn't at fault!

zx82 wrote:
gomme600 wrote:

Do you think we can try a wholeflash now? As we know it's flashing correctly we could try a normal and a byteswapped wholeflash (If you have one handy and it doesn't bother you that is).

I can make you a full image of a freshly installed unit containing the ST-and-Spansion-compatible CFE and 15.05.  I'll try to sort that out tomorrow.  Although...

gomme600 wrote:

Also, ethernet doesn't work at all, since flashing CFE the activity lights on my computer don't even flash, nothing at all

...if you're not even getting a link heartbeat light and can't ping the unit then it doesn't sound like CFE is ever running, and I don't see that anything will change with the whole-flash image.  (I'll still make it for you though.)

gomme600 wrote:

I only tried connecting serial after flashing CFE so I have never seen it working.

But it passes those continuity tests, right?  And you've checked that TX/RX aren't bridged together or anything?  Sorry to keep going on about the serial access but since it's so useful for debug when working, it seems worth exhausting all possibilities there.

Sorry that this unit is fighting you.  If it won't boot with the whole-flash either, one last thing before OpenOCD might be to try restoring your broken backup and then restoring the stock CFE over the top, hopefully giving you exactly what you started with.  I think I have a copy of the CFE my Spansion unit came with, which I could upload.  But that does sort of assume that your backup doesn't have any 0xffff artefacts from glitchy reads.

Hi. Not meaning to bug you, just wondered how you were doing with making the wholeflashes?
Happy late easter.
Thanks again!

(off-forum)

gomme600 wrote:

getting stuck at "Erasing block: 81 (addr=1fa00000) ... I don't suppose theres a way to skip erasing this block is there?

Flash is 16MiB i.e. 0x1000000 bytes. It's mapped in the BCM6358's memory at 0x1e000000. If you flash the whole 16MiB file (unzipped wholeflash) you should only be flashing 0x1e000000 through 0x1effffff (inclusive), so 0x1fa00000 is out of bounds. Are you giving tjtag a /length for this write, or letting it work that out itself?  If it's autodetecting and getting it wrong, you could just override it with /flash:custom /window:1e000000 /start:1e000000 /length:1000000.

(Last edited by zx82 on 2 Apr 2016, 10:18)

zx82 wrote:

(off-forum)

gomme600 wrote:

getting stuck at "Erasing block: 81 (addr=1fa00000) ... I don't suppose theres a way to skip erasing this block is there?

Flash is 16MiB i.e. 0x1000000 bytes. It's mapped in the BCM6358's memory at 0x1e000000. If you flash the whole 16MiB file (unzipped wholeflash) you should only be flashing 0x1e000000 through 0x1effffff (inclusive), so 0x1fa00000 is out of bounds. Are you giving tjtag a /length for this write, or letting it work that out itself?  If it's autodetecting and getting it wrong, you could just override it with /flash:custom /window:1e000000 /start:1e000000 /length:1000000.

Ok! That worked, erasing went perfectly! I guess the base configuration is based on hairydairymaid's original version for the WRT54 so we have to use -flash:custom for other routers. It's taking a while a expected, I'll tell you the outcome!

zx82 wrote:

(off-forum)

gomme600 wrote:

getting stuck at "Erasing block: 81 (addr=1fa00000) ... I don't suppose theres a way to skip erasing this block is there?

Flash is 16MiB i.e. 0x1000000 bytes. It's mapped in the BCM6358's memory at 0x1e000000. If you flash the whole 16MiB file (unzipped wholeflash) you should only be flashing 0x1e000000 through 0x1effffff (inclusive), so 0x1fa00000 is out of bounds. Are you giving tjtag a /length for this write, or letting it work that out itself?  If it's autodetecting and getting it wrong, you could just override it with /flash:custom /window:1e000000 /start:1e000000 /length:1000000.

Ok. So it flashed ok. I am going out this afternoon so I haven't got time to check serial at the moment (laptop already packed). It doesn't appear to have worked though... No activity on the ethernet port and all lights stay solid blue/purple (As you gave me a wholeflash I assume it should have booted and therefore the leds should have changed state). I don't suppose you have a stock wholeflash to try, maybe my unit just isn't getting along with the modified CFE...

zx82 wrote:

(off-forum)

gomme600 wrote:

getting stuck at "Erasing block: 81 (addr=1fa00000) ... I don't suppose theres a way to skip erasing this block is there?

Flash is 16MiB i.e. 0x1000000 bytes. It's mapped in the BCM6358's memory at 0x1e000000. If you flash the whole 16MiB file (unzipped wholeflash) you should only be flashing 0x1e000000 through 0x1effffff (inclusive), so 0x1fa00000 is out of bounds. Are you giving tjtag a /length for this write, or letting it work that out itself?  If it's autodetecting and getting it wrong, you could just override it with /flash:custom /window:1e000000 /start:1e000000 /length:1000000.

Well I believe that my serial port might be shorted. I am getting about 600 ohms between the pins... Could you check incase this is normal please ? I don't think it is but I'm no expert. It could just explain why it won't boot. And also why I was getting 3.3V on the RX pin. The problem is I can't see a short anywhere!

gomme600 wrote:

Well I believe that my serial port might be shorted. I am getting about 600 ohms between the pins... Could you check incase this is normal please?

Between RX and TX?  No, I see something in the low megaohms.  Between either data pin and ground, 600k.

zx82 wrote:
gomme600 wrote:

Well I believe that my serial port might be shorted. I am getting about 600 ohms between the pins... Could you check incase this is normal please?

Between RX and TX?  No, I see something in the low megaohms.  Between either data pin and ground, 600k.

Ok. I have 1200 ohms between Rx and Tx. Thats not normal then. Low megaohms would be a lot more unless you meant kilohms. Do you also have 3.3V on Rx?

I can't believe it!!! It works!!! I decided to make a parallele port cable today (The one with the 4 resistors), flashed the normal CFE on the wiki page using zjtag. (It took 171 seconds, a lot longer than the pi). Unplugged it, plugged it back in and I got serial output in TeraTerm! (I was using TeraTerm instead of minicom as I was on an XP box for the parallele port).
This is the command I used for anyone wondering: zjtag -flash:custom /window:1e000000 /start:1e000000 /length:20000 /cable:4 /BE

So it turns out that the raspberry pi was the issue the whole time, the old methods work best! Thanks zx82 for all the help and for your time!! Just need to install the image now but the most important part is working!

gomme600 wrote:

I can't believe it!!! It works!!! I decided to make a parallele port cable today...

You still have a machine with a parallel port?!?  Excellent smile

gomme600 wrote:

flashed the normal CFE on the wiki page using zjtag.

It'd be really helpful if you could try the anyflash CFE, so we can know for sure that one CFE will work on either type of flash seen in these units.

gomme600 wrote:

So it turns out that the raspberry pi was the issue the whole time, the old methods work best!

I'll add a note to the wiki page, but I don't consider this mystery solved, since 1) RPi worked fine for me on both flash types/both units; 2) you flashed an image and successfully read it back intact.  Still, zjtag is supposed to be dedicated to Broadcom's stuff, so I guess it should be the default choice.  Shame there's no GPIO support; while RPis aren't exactly great hardware they are ubiquitous and (in RPi Zero form) dirt cheap.

gomme600 wrote:

Just need to install the image now but the most important part is working!

Don't forget you can use the web interface for that bit.  Easier and quicker.

Hi, it would be nice having only one bootloader known to work on all flash chips. It can be a more solid info if we add only one CFE link to the wiki. A nice feauter could also be if the bootloader had the leds working properly, like some blinking led while loading or a power led on and the rest off. This way one could know if the CFE is alive without the serial console.

Some time ago btsimonh reported an issue with the reset/phone button for entering CFE failsafe:
http://openwrt.ebilan.co.uk/viewtopic.p … p=763#p762
No idea if this problem is really true, or if does it happen randonmly. Might be a better idea to use the reset button insead phone button. Initially the phone button was used because it's easier to press.

Regards

zx82 wrote:
gomme600 wrote:

I can't believe it!!! It works!!! I decided to make a parallele port cable today...

You still have a machine with a parallel port?!?  Excellent smile

gomme600 wrote:

flashed the normal CFE on the wiki page using zjtag.

It'd be really helpful if you could try the anyflash CFE, so we can know for sure that one CFE will work on either type of flash seen in these units.

gomme600 wrote:

So it turns out that the raspberry pi was the issue the whole time, the old methods work best!

I'll add a note to the wiki page, but I don't consider this mystery solved, since 1) RPi worked fine for me on both flash types/both units; 2) you flashed an image and successfully read it back intact.  Still, zjtag is supposed to be dedicated to Broadcom's stuff, so I guess it should be the default choice.  Shame there's no GPIO support; while RPis aren't exactly great hardware they are ubiquitous and (in RPi Zero form) dirt cheap.

gomme600 wrote:

Just need to install the image now but the most important part is working!

Don't forget you can use the web interface for that bit.  Easier and quicker.

I actually have a few machines with parallel ports! I hang on to old computers, infact the server is a pentium 3, 512mb of ram machine!

Ok, so I just tried the CFE named "CFE-BTHH2A-anyflash.bin" and it worked fine, took a bit less time to flash, 132 seconds.

I am also confused about the raspberry pi. It should have worked but didn't, makes no sence. Maybe something else was wrong with my configuration?

(Last edited by gomme600 on 3 Apr 2016, 13:00)

danitool wrote:

Hi, it would be nice having only one bootloader known to work on all flash chips. It can be a more solid info if we add only one CFE link to the wiki. A nice feauter could also be if the bootloader had the leds working properly, like some blinking led while loading or a power led on and the rest off. This way one could know if the CFE is alive without the serial console.

Some time ago btsimonh reported an issue with the reset/phone button for entering CFE failsafe:
http://openwrt.ebilan.co.uk/viewtopic.p … p=763#p762
No idea if this problem is really true, or if does it happen randonmly. Might be a better idea to use the reset button insead phone button. Initially the phone button was used because it's easier to press.

Regards

Well it seems that the anyflash version works on different chips, I confirmed it working on my spansion unit at least. I agree about the leds, unfortunatly I can't help with that, I can test things out but I wouldn't know how to modify the CFE myself.
I don't know about that issue because I used the serial console, I think it's easier to do it that way as the case is open anyway for Jtag. Does the reset button actually do anything at the moment?

The reset button can be used for entering Openwrt failsafe mode by pressing/releasing the button several times and fast enough while OpenWrt boots.

In CFE pressing the reset button shouldn't have any effect.

gomme600 wrote:

Ok, so I just tried the CFE named "CFE-BTHH2A-anyflash.bin" and it worked fine...

Thanks for the report.  I've updated the wiki to direct people to use that.

Of course, now that I've read that ebilan post danitool pointed to about buttons, I see it also suggests that on some units you can avoid all this JTAG fuss and perform the same USB/Samba hack that works on the Type B.

The discussion might have continued from here.