Initial support for Netgear Readynas Duo V2.

[ingmar-k]

Hi bodhi,

thank you very much for your great work. I was looking for a new base U-Boot for my Netgear Readynas Duo V2. The original implementation seems to be quite buggy, with a tendency to hang completely from time to time. Requiring a recovery afterwards.

Added my initial support, based on your Zyxel NSA325 work. It's not perfect, but for ~2 days of work, I am OK with it.

Would be great if you could integrate it. Best regards, Ingmar

[mibodhi]

Hi Ingmar,

Sure I will do that!

Thanks! -bodhi

[mibodhi]

Hi Ingmar,

There is also an issue with JFFS2. I had trouble rebuilding u-boot-kirkwood with JFFS2 using a later GCC version (gcc (Debian 8.3.0-6) 8.3.0).

I have rebased this u-boot-kirkwood repo locally to 2019.x and then 2021.07. It was built OK since 2019.x with JFFS2. So I did not try to fix this.

In my local build with your commits, I took out JFFS2 so I can compile with gcc 8.3.0-6.

My plan is eventually I will rebase this repo during releasing u-boot-kirkwood 2021.07.

-bodhi

[aaronbatiuk]

mibodhi,

I had the same compile issue with JFFS2 on Debian with gcc Debian 9.3.0-3. The fix is to open the problematic source file fs/jffs2/mini_inflate.c and look for the functions which the linker complains about... all of them are "inline". Change the definition from "inline ..." to "static inline ...". My theory is that the compiler is inlining all calls to the function, so does not create an actual callable version of it, but then the linker looks for the symbol for the function and can't find one since the compiler didn't create it. Using static means you want no externally visible symbol created so the linker never looks for it. This works since no other file is trying to call these functions (as it should be). If something else did call them, you could use "extern inline ..." and that should work in that case.

I had a similar issue with various files when re-building the old uBoot for Netgear Readynas NV+V2 from the Netgear open-source tarball. I had many unresolved symbols at link time; all resolved by fixing definitions or declarations of inline functions in various files. Obviously the compiler and/or linker behavior around inline functions changed sometime in the last several years.

[mibodhi]

mibodhi,

I had the same compile issue with JFFS2 on Debian with gcc Debian 9.3.0-3. The fix is to open the problematic source file fs/jffs2/mini_inflate.c and look for the functions which the linker complains about... all of them are "inline". Change the definition from "inline ..." to "static inline ...". My theory is that the compiler is inlining all calls to the function, so does not create an actual callable version of it, but then the linker looks for the symbol for the function and can't find one since the compiler didn't create it. Using static means you want no externally visible symbol created so the linker never looks for it. This works since no other file is trying to call these functions (as it should be). If something else did call them, you could use "extern inline ..." and that should work in that case.

I had a similar issue with various files when re-building the old uBoot for Netgear Readynas NV+V2 from the Netgear open-source tarball. I had many unresolved symbols at link time; all resolved by fixing definitions or declarations of inline functions in various files. Obviously the compiler and/or linker behavior around inline functions changed sometime in the last several years.

Thanks for the suggestion Aaron! I've been moving on to tracking u-boot 2023.04. And there were lot of changes in the sw infrastructure in u-boot. So I think I will take Ingmar's patches and retrofit to the new u-boot. This 2017.07 version is basically frozen.

-bodhi