ESP8266 Community Forum

- Mon Apr 24, 2017 3:37 am #65189 Hey all,

I'm currently in the process of building esp-open-sdk with the very latest crosstool-ng from crosstool-ng/crosstool-ng, for the latest gcc compiler (6.3.0) and Cygwin64.

I've found many of my previous issues that I documented have now gone away. My previous problem with 64 bit Cygwin and the plugins is now gone, as is the problem building with precompiled headers enabled and GDB's TUI interface included. These no longer need to be defined out in the crosstool build overrides, and all I had to do to get an almost working build was to copy the overlays, samples and local patches into the current crosstool-NG tree.

In the end I just needed to tweak the 0003-xtensa-add-HW-FPU-sequences-for-DIV-SQRT-RECIP-RSQRT patch a tiny bit and the toolchain built and seemed to work without issue. I then started building the rest of the open-sdk and this is where I have hit a couple of snags.

Firstly for anybody using Cygwin, they have made some changes to the way the implement Posix file permissions and the order of permissions under Windows causes some funky things to happen. Combined with this, I think crosstool-ng has now added stricter file and directory permissions on the final built toolchain, and the result is that you get file access errors when you install esptool, libcirom and the other libraries into the tree. I had to add chmod u+w commands to sections of the main Makefile where it copies or creates files.

Secondly, I have an open issue with crosstool-NG right now around creating a sysroot based toolchain - it appears that the default option for CT_USE_SYSROOT is not being set correctly and the result is that the sysroot directory system does not get created. This causes other parts of the Makefile to fail when you are looking for or creating libc or libhal etc. I had to manually add CT_USE_SYSROOT=y to the overrides and the problem fixed itself.

Finally, building esp-open-lwip fails because it uses -mforce-l32 and the patch for this was not added to my gcc6.3.0 build. Instead of removing this compiler option, I adjusted the Makefile to see if it would apply, and it ALMOST did, with only a couple of lines getting rejected. However, looking closely at the rejected patches, it appears that the -mauto-litpools option is now part of the code and this may conflict.

So I was wondering what the status of -mforce-l32 is, and whether it can be adjusted to coexist with the later code?

Here's the rejected patch from xtensa.md. The other one that was rjected was for xtensa.opt and was trivial, but this one looks a little more fiddly. All other patches applied perfectly.

Code: Select allxtensa.md.rej
--- gcc/config/xtensa/xtensa.md
+++ gcc/config/xtensa/xtensa.md
@@ -799,8 +802,8 @@
 })
 
 (define_insn "movhi_internal"
-  [(set (match_operand:HI 0 "nonimmed_operand" "=D,D,a,a,a,U,*a,*A")
-   (match_operand:HI 1 "move_operand" "M,d,r,I,U,r,*A,*r"))]
+  [(set (match_operand:HI 0 "nonimmed_operand" "=D,D,a,a,a,a,U,*a,*A")
+   (match_operand:HI 1 "move_operand" "M,d,r,I,Y,Z,r,*A,*r"))]
   "xtensa_valid_move (HImode, operands)"
   "@
    movi.n\t%0, %x1
@@ -808,12 +811,13 @@
    mov\t%0, %1
    movi\t%0, %x1
    %v1l16ui\t%0, %1
+   ssa8l\t%B1 ; srli\t%0, %B1, 2 ; slli\t%0, %0, 2 ; %v1l32i\t%0, %0, 0 ; srl\t%0, %0 ; extui\t%0, %0, 0, 16
    %v0s16i\t%1, %0
    rsr\t%0, ACCLO
    wsr\t%1, ACCLO"
-  [(set_attr "type"   "move,move,move,move,load,store,rsr,wsr")
+  [(set_attr "type"   "move,move,move,move,load,load,store,rsr,wsr")
    (set_attr "mode"   "HI")
-   (set_attr "length"   "2,2,3,3,3,3,3,3")])
+   (set_attr "length"   "2,2,3,3,3,18,3,3,3")])
 
 ;; 8-bit Integer moves
 


The relevant section of xtensa.md

Code: Select allxtensa.md
})

(define_insn "movhi_internal"
  [(set (match_operand:HI 0 "nonimmed_operand" "=D,D,a,a,a,a,U,*a,*A")
   (match_operand:HI 1 "move_operand" "M,d,r,I,Y,U,r,*A,*r"))]
  "xtensa_valid_move (HImode, operands)"
  "@
   movi.n\t%0, %x1
   mov.n\t%0, %1
   mov\t%0, %1
   movi\t%0, %x1
   movi\t%0, %1
   %v1l16ui\t%0, %1
   %v0s16i\t%1, %0
   rsr\t%0, ACCLO
   wsr\t%1, ACCLO"
  [(set_attr "type"   "move,move,move,move,move,load,store,rsr,wsr")
   (set_attr "mode"   "HI")
   (set_attr "length"   "2,2,3,3,3,3,3,3,3")])

;; 8-bit Integer moves


- Mon Apr 24, 2017 5:16 am #65192

So I was wondering what the status of -mforce-l32 is, and whether it can be adjusted to coexist with the later code?

Patch for 6.2.0 is available here, status: completely untested.
Bigger picture status: it's not upstreamable in its current form, but it's probably worth trying to upstream it after some cleaning. At the very least it needs to support both little- and big-endian targets.

- Mon Apr 24, 2017 6:24 am #65193

So I was wondering what the status of -mforce-l32 is, and whether it can be adjusted to coexist with the later code?

Patch for 6.2.0 is available here, status: completely untested.

... allow me to change that word 'completely' for you

thanks mate - will check that out against 6.3.0

Word of warning - there has been a lot of change between crosstool-NG 1.22 and 1.23, and my Makefile based builds of esp-open-sdk are breaking constantly with dir/file permissions errors, and there is also something very weird with the default sysroot settings (fixed by explicitly adding CT_USE_SYSROOT=y to the override file).

I still don't know if the file stuff is caused partially by Cygwin's changes but watch out for them - they lock down just about every location in the tool chain, making almost all the other targets fail when they try to install

- Mon Apr 24, 2017 6:49 am #65195 OK dumb question...

How can I save that commit as a patch/diff? Do I have to clone the whole repo or can I do it through the web interface?