Hello, de JG1UAA

[jg1uaa]

Hello,

I am trying to build OpenGD77 from source code zipball.
----
It should be written at other place but I have no time to find now so I write here
(If we were at GitHub, simply create issue... So guide me suitable place, please!)

To obtain OpenGD77.bin, we use codec_cleaner; no source program.
It clears (fills with 0xff) regions at 0x00000400~0x00003fff and 0x0004c000~0x00076fff region of firmware.bin but I think this is very dangerous because the linker script does not define clearly about codec_bin_section 1 and 2.

Here is the remedy, diiff for linkerscripts/firmware_newlib.ld.

Code: Select all

--- firmware_newlib.ld.old	2021-06-28 20:24:03.577940493 +0900
+++ firmware_newlib.ld	2021-06-28 20:32:43.234621443 +0900
@@ -40,9 +40,12 @@
 
     .codec_bin_section_1 : ALIGN(4)
     {
+        FILL(0xff)
        . = ABSOLUTE(0x4400) ;
        *(.codec_bin_section_1)
         KEEP(*(.codec_bin_section_1))
+        FILL(0xff)
+       . = ABSOLUTE(0x8000) ;
     } > PROGRAM_FLASH
 
     .text_main : ALIGN(4)
@@ -106,9 +109,12 @@
 
     .codec_bin_section_2 : ALIGN(4)
     {
+        FILL(0xff)
         . = ABSOLUTE(0x54000) ;
        *(.codec_bin_section_2)
         KEEP(*(.codec_bin_section_2))
+        FILL(0xff)
+        . = ABSOLUTE(0x7f000) ;
     } > PROGRAM_FLASH
 
     /* BSS section for SRAM_LOWER */

I think this diff can delete codec_cleaner and codec_bin_section_1/2 binary.

73 to all,

[F1RMB]

Hi,

The purpose of codec_cleaner is to ensure the distributed firmware don't have any trace of the codec.
Some developers aren't using standard flashing process, so they embed the codec in the bin file.

The size of the regions are known, there is no "danger" here

Hence, this linker script change couldn't be accepted.


Cheers.
---
Daniel

[jg1uaa]

Hello,

> The size of the regions are known, there is no "danger" here

This is well-known among inside developers, but how about for outside? Is there any information about that in _released_ source code?
In fact I used 0-byte blobs first, codec_cleaner was crashed with core dump...
I know that codec_cleaner can produce dummy blob, but there is no source code (I think this is also problem) so we only know correct file size from products.

The size of dummy blob (and previously extracted from codec_files_creator.exe) is 15360bytes(section1)/176128byte(section2). But the method from at http://www.opengd77.com/viewtopic.php?p=14786#p14791 produces 16384/163984bytes. Which is correct?

[F1RMB]

Hi,


Hold on a sec, none of the size you mentioned are correct. It seems there is a "slight" problem here, checking...


Cheers.
---
Daniel

[F1RMB]

Hi,


Okay, please, re-download the OpenGD77_buildtools.zip, it now contains the correct version of the tools.

"This is well-known among inside developers, but how about for outside"
As it was stated in the current development release thread, in the next source release, a readme.txt file will be located in the linkerdata surbir, plus, a batch file and a bash script (prepare.bat & prepare) will be available at the topdir, which do that for the end-user.


Cheers.
---
Daniel

[jg1uaa]

I downloaded new version of OpenGD77_buildtools.zip and tested with blank file by "dd if=/dev/zero of=input.bin bs=1024 count=4096". no problem as you expected.

old:
- codec_bin_section_1.bin 15360bytes
- codec_bin_section_2.bin 176128bytes
- codec_cleaner 0x00000400~0x00003fff, 0x0004c000~0x00076fff

new:
- codec_bin_section_1.bin 15360bytes
- codec_bin_section_2.bin 163984bytes
- codec_cleaner 0x00000400~0x00003fff, 0x00050000~0x0007808f

And,

> As it was stated in the current development release thread, in the next
> source release, a readme.txt file will be located in the linkerdata surbir,
> plus, a batch file and a bash script (prepare.bat & prepare) will be
> available at the topdir, which do that for the end-user.

sounds good! thanks.

73,