Weird direction issue with XYZY PrintNC

My configuration is a PrintNC (a dual Y ganged CNC machine) with a FlexiHAL board with a uFlexiNET Ethernet board, and I am connecting it directly with an Ethernet cable to a Dell Optiplex 780 , running the latest LinuxCNC image (linuxcnc_2.9.8-amd64.hybrid.iso).
I flashed the board with remora-eth, and uploaded the attached configuration (FlexiHAL-config.txt). I also attached the hal and ini files.
What happens is, that I can home and move X and Z correctly, but not Y. The gantry goes back to the endstops, and I can see the homing sequence almost completing successfully, but at the end, one side starts moving to the opposite direction, towards the front.
The wiring and driver setting are identical on both Y sides, and the same hardware works perfectly with grblHAL, so I don't think it's a wiring or driver issue.
Any help is greatly appreciated.

Yes, the moment I pressed submit I realized I forgot the attachments, please see them attached now.





The joints are for sure not reversed, I have the exact same wiring and driver settings on both sides, and as I mentioned, it works perfectly with grblHAL.

The weirdness is actually exactly it. I did try reversing one of the Y joints by inverting the scale parameter and the gantry moved correctly in axis mode when jogging (before homing), but then, when I started homing, the joints started to move the opposite directions, starting to tear the machine apart. Like it had a split mind. When jogging, wants to move reversed, when homing, straight. Perhaps one side starting to move the opposite direction at the end of the homing is a result of that, as the final position is taken, the move is using the same "method", as jogging.

I am now compiling the remora-eth firmware in debug mode (USE_DEBUG=1), perhaps I will see something in the debug terminal (PC connected through USB)? 

I posted the question on the linuxcnc channel on the PrintNC Discord server too, and mikemacwillie pointed out the problem in my FlexiHAL-config.txt file. The Y limit input was inverted, so the machine thought it was already triggered when the carriage was nowhere near.

After changing it from True to False, I also had to revise the HOME and HOME_OFFSET parameters, as I interpreted them incorrectly.

Please, see my correct config files attached.