board: add support for ARC HS Development Kit (HSDK)

Synopsys DesignWare HSDK (which stands for ARC HS Development Kit) is the latest and greatest development platform that sports quad-core ARC HS38 in real silicon.

Most noticeable features of the board are:
* Quad-core ARC HS38 CPU running at 1GHz
* 4Gb of DDR
* Built-in Vivante GPU (well supported via open source Etnaviv drivers)
* Built-in Wi-Fi/Bluetooth module (RedPine RS-9113)

 board/synopsys/hsdk/genimage-hsdk.cfg | 26 +++++++++++++++++++++++++

+mkenvimage -s 0x4000 -o output/images/uboot.env ${BOARD_DIR}/uboot.env.txt

+tar czf output/images/sdcard.img.tar.gz --directory="./output/images" sdcard.img

Hello,

Quoted 4 lines · Evgeniy Didin

Synopsys DesignWare HSDK (which stands for ARC HS Development Kit) is the latest and greatest development platform that sports quad-core ARC HS38 in real silicon.

Quoted 6 lines

Most noticeable features of the board are:
* Quad-core ARC HS38 CPU running at 1GHz
* 4Gb of DDR
* Built-in Vivante GPU (well supported via open source Etnaviv drivers)
* Built-in Wi-Fi/Bluetooth module (RedPine RS-9113)

Nice. Do you send free boards ? :-)

Quoted 1 line

 board/synopsys/hsdk/genimage-hsdk.cfg | 26 +++++++++++++++++++++++++

genimage.cfg is enough as a name I'd say.

Quoted 1 line

+mkenvimage -s 0x4000 -o output/images/uboot.env ${BOARD_DIR}/uboot.env.txt

This can be done using BR2_TARGET_UBOOT_ENVIMAGE.

Review

Quoted 7 lines

(quoted diff) +7 -0

+
+genimage                           \
+        --rootpath "${TARGET_DIR}"     \
+        --tmppath "${GENIMAGE_TMP}"    \
+        --inputpath "${BINARIES_DIR}"  \
+        --outputpath "${BINARIES_DIR}" \
+        --config "${GENIMAGE_CFG}"

This should instead use the generic support/scripts/genimage.sh

Quoted 1 line

+tar czf output/images/sdcard.img.tar.gz --directory="./output/images" sdcard.img

And this is not needed.

So basically, you can remove your post-image script, and point to support/scripts/genimage.sh directly.

Finally, add an entry in the DEVELOPERS file,

and update
the .gitlab-ci.yml file by running "make .gitlab-ci.yml" and committing the result.

Quoted 1 line

Nice. Do you send free boards ? :-)

If you guys are interested I'll try to make sure you'll get one. Seriously. But it won't happen before later next year anyways :)

There's one caveat though.
On that board we use SD-card as a storage for uImage, rootfs and among other things U-Boot environment. But compared to some ARM boards we keep it on the first FAT partiotion, not just put as a raw blob on SD-card before filesystem starts.

This is perfectly possible with up-to-date U-Boot - everything is already thee, just say that environment will be on FAT partition like that:
----------------------------->8---------------------- CONFIG_ENV_IS_IN_FAT=y
CONFIG_ENV_FAT_INTERFACE="mmc"
CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" ----------------------------->8----------------------

And by default U-Boot will look for a file with name "uboot.env", see
http://git.denx.de/?p=u-boot.git;a=blob;f=env/Kconfig#l394

But in Buildroot for some reason "uboot-env.bin" is generated.

So what we may do here:
1) We may switch to "uboot-env.bin" in our U-Boot.
2) We may keep using post build script... or
3) We may switch to more common U-Boot-wise "uboot.env" with:
----------------------------->8----------------------

board/altera/socrates_cyclone5/genimage.cfg +1 -1

index 63fef8ba4764..04d30490cb4d 100644
@@ -35,7 +35,7 @@ image sdcard.img {
 
        partition uboot-env {
                in-partition-table = "no"
-               image = "uboot-env.bin"
+               image = "uboot.env"
                offset = 17408 # 512 * 34 -> just after gpt
        }
 

board/altera/socrates_cyclone5/readme.txt +1 -1

index 4e78feef11a5..2e34c3d31f85 100644
@@ -30,7 +30,7 @@ Following files will be generated in output/images
 ??? u-boot-spl.bin.crc
 ??? u-boot.bin
 ??? u-boot.img
-??? uboot-env.bin
+??? uboot.env
 ??? uboot.img
 ??? zImage
 

boot/uboot/Config.in +1 -1

index 2ae38e95d5af..d6fd3672aee0 100644
@@ -378,7 +378,7 @@ menuconfig BR2_TARGET_UBOOT_ENVIMAGE
          Generate a valid binary environment image from a text file
          describing the key=value pairs of the environment.
 
-         The environment image will be called uboot-env.bin.
+         The environment image will be called uboot.env.
 
 if BR2_TARGET_UBOOT_ENVIMAGE
 

boot/uboot/uboot.mk +1 -2

index 14a8cc949a33..aaecf4d466cf 100644
@@ -246,7 +246,7 @@ define UBOOT_INSTALL_IMAGES_CMDS
                        $(HOST_DIR)/bin/mkenvimage -s $(BR2_TARGET_UBOOT_ENVIMAGE_SIZE) \
                        $(if $(BR2_TARGET_UBOOT_ENVIMAGE_REDUNDANT),-r) \
                        $(if $(filter BIG,$(BR2_ENDIAN)),-b) \
-                       -o $(BINARIES_DIR)/uboot-env.bin -)
+                       -o $(BINARIES_DIR)/uboot.env -)
        $(if $(BR2_TARGET_UBOOT_BOOT_SCRIPT),
                $(HOST_DIR)/bin/mkimage -C none -A $(MKIMAGE_ARCH) -T script \
                        -d $(call qstrip,$(BR2_TARGET_UBOOT_BOOT_SCRIPT_SOURCE)) \
----------------------------->8----------------------  

What do you think?

Quoted 5 lines

This should instead use the generic support/scripts/genimage.sh

Quoted 1 line

+tar czf output/images/sdcard.img.tar.gz --directory="./output/images" sdcard.img

And this is not needed.

Well IMHO compression of the image makes sense because that way we may generate images with larger FAT-partition without bumping size of the output image.

See we always allocate a bit more space for FAT partition (or it is applicable to any not-last partiotion - not sure about that) compared to what we need just to make sure it's enough space for our stuff. Moreover I'd like to have some more space so I may for example put 2 uImages side by side and switch between them later on and do it all without re-formatting of the SD-card.

And given how large SD-cards these days are I'm fine with allocating even 100Mb for first FAT partiotion. Now if we don't compress sdcard.img it will be of size 100+ Mb. But if we gzip it then we only have size of real payload, i.e. ~6-7 Mb while keeping a lot of flexibility for image user.

Not to mention a case of sharing built images.

That said I'd rather prefer to either compress images by default (does it really hurt?) or at least have it as an option.

Hello,

On Wed, 13 Dec 2017 18:04:04 +0000, Alexey Brodkin wrote:

Quoted 1 line

But in Buildroot for some reason "uboot-env.bin" is generated.

"some reason" = back then, there was no support in U-Boot for reading the environment from a file, or at least we didn't know about this.

Quoted 4 lines

So what we may do here:
1) We may switch to "uboot-env.bin" in our U-Boot.
2) We may keep using post build script... or
3) We may switch to more common U-Boot-wise "uboot.env" with:

I think option (3) is the best. But it has a drawback: it breaks backward compatibility for existing users that rely on the file being named uboot-env.bin. So instead, you could add a new U-Boot option that allows to customize the name of the generated image. By default it would be uboot-env.bin to keep backward compatibility, but it could be set to a different value in your defconfig.

Or we decide to break the backward compatibility :)

Quoted 14 lines

Quoted 5 lines

This should instead use the generic support/scripts/genimage.sh

Quoted 1 line

+tar czf output/images/sdcard.img.tar.gz --directory="./output/images" sdcard.img

And this is not needed.

Well IMHO compression of the image makes sense because that way we may generate images with larger FAT-partition without bumping size of the output image.

See we always allocate a bit more space for FAT partition (or it is applicable to any not-last partiotion - not sure about that) compared to what we need just to make sure it's enough space for our stuff. Moreover I'd like to have some more space so I may for example put 2 uImages side by side and switch between them later on and do it all without re-formatting of the SD-card.

Quoted 8 lines

And given how large SD-cards these days are I'm fine with allocating even 100Mb for first FAT partiotion. Now if we don't compress sdcard.img it will be of size 100+ Mb. But if we gzip it then we only have size of real payload, i.e. ~6-7 Mb while keeping a lot of flexibility for image user.

Not to mention a case of sharing built images.

That said I'd rather prefer to either compress images by default (does it really hurt?) or at least have it as an option.

I'm not sure we want to solve this in your specific post-image script, it's a more generic problem. Though I agree we don't have a good way of solving it right now.

Also, creating a tarball for just one file is a bit weird, you could just gzip sdcard.img to produce sdcard.img.gz.

Quoted 8 lines

I think option (3) is the best. But it has a drawback: it breaks backward compatibility for existing users that rely on the file being named uboot-env.bin. So instead, you could add a new U-Boot option that allows to customize the name of the generated image. By default it would be uboot-env.bin to keep backward compatibility, but it could be set to a different value in your defconfig.

Or we decide to break the backward compatibility :)

Well here again we're bumping to a situation that "something might be used by BR users and we don't know what and how" :)

I mean in upstream Buildroot (as of today, i.e. without HSDK support) "uboot-env.bin" is only used for dumping binary data into SD-card image, which essentially means file name makes no sense as long as genimage.cfg mentions it correctly and as it might be seen from my patch proposal it is already handled (proabably I should have left the patch above in place so you don't need to look-up my previous email).

So our only concern might be people use "uboot-env.bin" on their own.

Quoted 23 lines

Quoted 22 lines

Quoted 5 lines

This should instead use the generic support/scripts/genimage.sh

Quoted 1 line

+tar czf output/images/sdcard.img.tar.gz --directory="./output/images" sdcard.img

And this is not needed.

Well IMHO compression of the image makes sense because that way we may generate images with larger FAT-partition without bumping size of the output image.

See we always allocate a bit more space for FAT partition (or it is applicable to any not-last partiotion - not sure about that) compared to what we need just to make sure it's enough space for our stuff. Moreover I'd like to have some more space so I may for example put 2 uImages side by side and switch between them later on and do it all without re-formatting of the SD-card.

And given how large SD-cards these days are I'm fine with allocating even 100Mb for first FAT partiotion. Now if we don't compress sdcard.img it will be of size 100+ Mb. But if we gzip it then we only have size of real payload, i.e. ~6-7 Mb while keeping a lot of flexibility for image user.

Not to mention a case of sharing built images.

That said I'd rather prefer to either compress images by default (does it really hurt?) or at least have it as an option.

Quoted 6 lines

I'm not sure we want to solve this in your specific post-image script, it's a more generic problem. Though I agree we don't have a good way of solving it right now.

Also, creating a tarball for just one file is a bit weird, you could just gzip sdcard.img to produce sdcard.img.gz.

That's exactly what we do: we compress only resulting "sdcard.img" into "sdcard.img.tar.gz".

Hello,

Quoted 19 lines · Alexey Brodkin

Quoted 8 lines

I think option (3) is the best. But it has a drawback: it breaks backward compatibility for existing users that rely on the file being named uboot-env.bin. So instead, you could add a new U-Boot option that allows to customize the name of the generated image. By default it would be uboot-env.bin to keep backward compatibility, but it could be set to a different value in your defconfig.

Or we decide to break the backward compatibility :)

Well here again we're bumping to a situation that "something might be used by BR users and we don't know what and how" :)

I mean in upstream Buildroot (as of today, i.e. without HSDK support) "uboot-env.bin" is only used for dumping binary data into SD-card image, which essentially means file name makes no sense as long as genimage.cfg mentions it correctly and as it might be seen from my patch proposal it is already handled (proabably I should have left the patch above in place so you don't need to look-up my previous email).

Quoted 1 line

So our only concern might be people use "uboot-env.bin" on their own.

I think we should simply make the output file name configurable, which solves your use case, and preserves backward compatibility. This should all be explained in the commit log.

Quoted 30 lines

Quoted 29 lines

Quoted 14 lines

Quoted 5 lines

This should instead use the generic support/scripts/genimage.sh

Quoted 1 line

+tar czf output/images/sdcard.img.tar.gz --directory="./output/images" sdcard.img

And this is not needed.

Well IMHO compression of the image makes sense because that way we may generate images with larger FAT-partition without bumping size of the output image.

See we always allocate a bit more space for FAT partition (or it is applicable to any not-last partiotion - not sure about that) compared to what we need just to make sure it's enough space for our stuff. Moreover I'd like to have some more space so I may for example put 2 uImages side by side and switch between them later on and do it all without re-formatting of the SD-card.

Quoted 8 lines

And given how large SD-cards these days are I'm fine with allocating even 100Mb for first FAT partiotion. Now if we don't compress sdcard.img it will be of size 100+ Mb. But if we gzip it then we only have size of real payload, i.e. ~6-7 Mb while keeping a lot of flexibility for image user.

Not to mention a case of sharing built images.

That said I'd rather prefer to either compress images by default (does it really hurt?) or at least have it as an option.

I'm not sure we want to solve this in your specific post-image script, it's a more generic problem. Though I agree we don't have a good way of solving it right now.

Also, creating a tarball for just one file is a bit weird, you could just gzip sdcard.img to produce sdcard.img.gz.

Quoted 1 line

That's exactly what we do: we compress only resulting "sdcard.img" into "sdcard.img.tar.gz".

No, the code creates a tarball:

tar czf output/images/sdcard.img.tar.gz --directory="./output/images" sdcard.img

Which is useless when compressing a single file. Just compress the file with gzip, no need to create a tarball.

But again, I recommend against that, as none of our defconfigs do this currently.

If you want to solve this problem, solve it separately, otherwise your defconfig will wait for ages before being merged.