raburton / esp8266

Various bits of code for ESP8266
http://richard.burtons.org/
183 stars 47 forks source link

Commit bba5f02 breaks rboot-sampleproject using ESP-01 #8

Closed dranger003 closed 9 years ago

dranger003 commented 9 years ago

This appears to be related to the updated ld scripts and I can't figure out why but the ESP-01 no longer boots (zero output - not even rboot) starting at this commit. Works as expected if compiled using the previous commit. Maybe I have to update the other ld scripts in rboot-sampleproject?

raburton commented 9 years ago

Are you using sdk 1.1.1? That's where the changes to the ld files come from, and it may not work if you use these linker scripts with an older version.

Are you saying that both rboot and rboot-sample build fine with this commit, but they just don't work when you run them? I've been building rBoot all weekend with these linker scripts without any problem. I'll double check the sample project though as not used that is a while.

raburton commented 9 years ago

Make sure you've pulled the fix for the esptool2 and rebuilt it as well, there was a bug that could cause a bad checksum, and so give you a rom that wouldn't boot. You can also enable the delay at the start of rBoot so you can jump in quick with a console and see what the messages are on the first boot immediately after the flashing completes.

dranger003 commented 9 years ago

Yes, I'm using SDK 1.1.1 as per https://github.com/raburton/esp8266/blob/bba5f0228ace4a79a1acba4ddde7c659fd48baa6/rboot-sampleproject/Makefile#L8

I'm referring to commit bba5f0 because this where the ESP-01 stops working but even with an updated master I have the same problem. Everything compiles fine (esptool2, rboot and rboot-sampleproject) however I get no output (other than a little bit of garbage). Even with the delay, I get the same results. It's as if the SDK wasn't properly initiating the boot (maybe because rboot isn't at the right address?).

I see from your commit the ld scripts were updated for the rboot-sampleproject so I'm assuming they are right? Are using an ESP-12 or nodemcu? Have you tried the rboot-sampleproject with the latest master?

raburton commented 9 years ago

Yes, all the ld scripts were updated to sdk 1.1.1, so that should be fine. I did build the rboot-sample project this morning for you, but I honestly can't remember if I ran it! I think I did, but I had a lot of things to sort out this morning before work.

The garbage you are seeing is most likely the rboot messages, but the terminal isn't synchronised yet. Try uncommenting the delay in rboot and connect the serial terminal immediately after flashing completes (in the two second delay). This should allow you to see the messages on the first boot.

Did you use the updated esptool2? It doesn't look like you've merged that with your fork yet. The checksum bug only started happening over the weekend (although it has been there since the start), with 3 different people hitting it, so it might have something to do with the change in the linker script affecting the size of the output (the bug only occurs when the image needs some padding).

dranger003 commented 9 years ago

I'm running off your repo and not mine so don't get fooled by mine been outdated (I switched to yours to ensure I'm running the same code - thus I'm using the updated esptool2).

I did uncomment the delay, and nothing changes (not even when the garbage appears). I don't believe the garbage being the rboot message being unsynchronized but maybe I'm wrong.

I won't be able to do more testing until tonight but if I recall I tried flashing just rboot alone at 0x00000 with the latest master and was able to see the rboot output properly (but obviously the boot was fatal since no rom was flashed with it). However if I add the rboot-sampleproject roms then I get no more output.

raburton commented 9 years ago

Hmm, that doesn't make sense then. There is no reason that if rboot works on its own and is displaying messages that it wouldn't even get that far when there is also a rom on the flash. Unless putting the rom on the flash is resulting in rboot being erased / corrupted. The esp01 only has a very small flash, is the rom too big for the flash? Just a thought. Otherwise not really sure. I'll do some more testing when I get home, but I'm on call this evening so I won't be home till late.

dranger003 commented 9 years ago

For your information I'm flashing using esptool.py like this (I'm testing on ESP-01 with 512K flash so yes, small mem - but I adjusted the rom1.ld script):

./esptool.py --port /dev/ttyUSB0 --baud 115200 write_flash -fs 4m 0x00000 rboot.bin 0x02000 rom0.bin 0x42000 rom1.bin

Interesting note also is that if I add this portion "0x7c000 blank4.bin" at the end of esptool.py then I get no more output (even with pre-1.1.1 SDK). Not sure why this is happening as my rom are clearly smaller than 0x3C000.

raburton commented 9 years ago

Hmm, certainly sounds like something funny is happening with the flash. Two things you could try, just flashing rboot and rom0, not rom1 and see if that makes any difference. Try reading the flash back after all flashed and see if it's the same as what you wrote, or if it's been corrupted.

dranger003 commented 9 years ago

There are a few differences in the ld scripts when comparing to the SDK - I'm assuming these are "normal"?

rboot-stage2a.ld:

  iram1_0_seg :                         org = 0x4010FC00, len = 0x400
  irom0_0_seg :                         org = 0x40240000, len = 0x3C000

eagle.app.v6.ld (rboot):

  iram1_0_seg :                         org = 0x40100000, len = 0x8000
  irom0_0_seg :                         org = 0x40200000, len = 0x3C000

eagle.app.v6.ld (SDK):

  iram1_0_seg :                         org = 0x40100000, len = 0x8000
  irom0_0_seg :                         org = 0x40240000, len = 0x3C000

The breaking commit is updating rboot-stage2a.ld:

-  irom0_0_seg :                         org = 0x40200000, len = 0x3C000
+  irom0_0_seg :                         org = 0x40240000, len = 0x3C000
raburton commented 9 years ago

You're saying if you switch backwards and forwards between 0x40200000 & 0x40240000 in rboot-stage2a.ld it works and doesn't work?

That doesn't make any sense, because rBoot doesn't compile any code to irom (flash isn't mapped when rBoot runs, so it couldn't use it if it did). The only reason that line changed is because there was no reason for it to have been different from the sdk linker file in the first place, so I reset it back to the stock value.

raburton commented 9 years ago

Double checked sample project is working fine here.

dranger003 commented 9 years ago

On ESP-01?

raburton commented 9 years ago

No I don't have one one those. I do know of someone who is using rBoot built from the latest source with sdk 1.1.1 on an ESP-01 though (without problems).

You didn't confirm if it's that one single line that makes the difference?

dranger003 commented 9 years ago

Now this is interesting. If I flash with -fs 8m and use 0x82000 then it works. Anyway to know if I really have an 8m flash chip?

raburton commented 9 years ago

"esptool flash_id" and look up the chip

I wonder if it wraps and is writing back to the first part of the chip again?

dranger003 commented 9 years ago

Manufacturer: c8 Device: 4013

I can switch from rom0 to rom1 and vice-versa but ota fails (either from rom0 or rom1) and the chip becomes unusable afterwards.

dranger003 commented 9 years ago

Okay, I just received some new ESP-01 with 8m. Manufacturer: c8 Device: 4014

With these ones everything works, including ota.

raburton commented 9 years ago

Your first one looks like a GD25Q40 4Mbit chip, so it must be wrapping or something. You could try changing the flash order on the command line and flashing the roms before rBoot. I know Pete Scargill had to do that with some of his ESP-01 previously. Or don't flash the second rom at all, just rBoot and the first (you can then use OTA to install the second one).

dranger003 commented 9 years ago

Something wicked is happening... if I don't flash rom1 then I can boot rom0 then ota and it does switch to rom1 but doing ota again from rom1 gets me back in rom1 forever. Even switch or ota again won't get me back to rom0.

raburton commented 9 years ago

That's pretty odd. I think the only to figure it out is going to be erase flash (known starting point), do like you just said (r + 0 then ota 1), then read the entire flash back and see what you've actually got!

dranger003 commented 9 years ago

Another interesting point is that I get a "system param error" right after your line that says "Writing default boot config.\nBooting rom 0.\n" then a full page of 00's then the "rBoot Sample Project". But once I ota at least once then the "system param error" goes away. This is happening on all my ESP-01 4m (I have 5 of them purchased from Adafruit).

dranger003 commented 9 years ago

Well maybe flashing 8m of zeros cleaned up some mess because now I can ota and switch rom0/1. But this is still only if I flash rom0 only then ota rom1. Then all works as expected, including ota from rom1 to get back in rom0.

raburton commented 9 years ago

That's not an error from rBoot, maybe from the SDK looking at it's config in the last few sectors? Then hex dumping the contents. Yay, so essentially it's working then. As I say Pete hd issues on ESP01s with flashing, I think basically it seemed to be erasing an extra sector when it was being flashed.

Actually, I'd forgotten but it does the same on my ESP12s, just it's never caused me a problem. If I reflash rBoot in the first sector, the second sector gets erased, so it always has to generate a new config.

dranger003 commented 9 years ago

Yep, this is working now even though I don't have a clear idea what's causing rom1 esptool flash to render the device unusable. I have some ESP-12's as well that I'll try later.