[v3,1/2] host-zynq-boot-bin: new package

From: Jan Viktorin <viktorin@rehivetech.com>

The package creates file images/boot.bin to boot
Xilinx Zynq based boards. It might not work with
U-Boot older then 2015.07.

The script zynq-boot-bin.py is contained in the
Xilinx repository of U-Boot (it is not in upstream).

Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
---
Changes:
 * v0->v1: create this package instead of patching U-Boot by zynq-boot-bin.py
 * v1->v2: call zynq-boot-bin.py from the package
 * v2->v3: remove python deps, do not download U-Boot, just the script

 package/Config.in.host                 |  1 +
 package/zynq-boot-bin/Config.in.host   |  8 ++++++++
 package/zynq-boot-bin/zynq-boot-bin.mk | 24 ++++++++++++++++++++++++
 3 files changed, 33 insertions(+)
 create mode 100644 package/zynq-boot-bin/Config.in.host
 create mode 100644 package/zynq-boot-bin/zynq-boot-bin.mk

Jan, All,

On 2015-06-23 14:49 +0200, Jan Viktorin spake thusly:
> From: Jan Viktorin <viktorin@rehivetech.com>
> 
> The package creates file images/boot.bin to boot
> Xilinx Zynq based boards. It might not work with
> U-Boot older then 2015.07.
> 
> The script zynq-boot-bin.py is contained in the
> Xilinx repository of U-Boot (it is not in upstream).
> 
> Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
[--SNIP--]
> diff --git a/package/zynq-boot-bin/zynq-boot-bin.mk b/package/zynq-boot-bin/zynq-boot-bin.mk
> new file mode 100644
> index 0000000..aff4593
> --- /dev/null
> +++ b/package/zynq-boot-bin/zynq-boot-bin.mk
> @@ -0,0 +1,24 @@
> +################################################################################
> +#
> +# zynq-boot-bin
> +#
> +################################################################################
> +
> +ZYNQ_BOOT_BIN_VERSION = xilinx-v2015.1
> +ZYNQ_BOOT_BIN_SOURCE = zynq-boot-bin.py
> +ZYNQ_BOOT_BIN_SITE = https://raw.githubusercontent.com/Xilinx/u-boot-xlnx/$(ZYNQ_BOOT_BIN_VERSION)/tools

Missing licensing information:
    ZYNQ_BOOT_BIN_LICENSE = foo license...
    ZYNQ_BOOT_BIN_LICENSE_FILES = License-file

> +HOST_ZYNQ_BOOT_BIN_INSTALL_STAGING = NO
> +HOST_ZYNQ_BOOT_BIN_INSTALL_IMAGES = YES

Since this is a host-only package, you need not specify either;
  - install_staging already defaults to no,
  - both are anyway only valid for target packages.

> +HOST_ZYNQ_BOOT_BIN_DEPENDENCIES = uboot
> +
> +define HOST_ZYNQ_BOOT_BIN_EXTRACT_CMDS
> +	@cp $(DL_DIR)/$(ZYNQ_BOOT_BIN_SOURCE) $(@D)
> +endef
> +
> +define HOST_ZYNQ_BOOT_BIN_BUILD_CMDS
> +	@env python2 $(@D)/zynq-boot-bin.py -o $(BINARIES_DIR)/boot.bin \

That mught be an indication that it should depend on host-python, no?

> +		-u $(BINARIES_DIR)/$(notdir $(call qstrip,$(BR2_TARGET_UBOOT_SPL_NAME)))
> +endef

Although what you wrote does work, it is not absolutely correct: the
build commands should just really build, not install anything in the
output directories.

You should generate the files in the package build directory, and
provide a command that does the install (even if it is just copying the
generated files).

> +$(eval $(host-generic-package))

But, then since you install in $(BINARIES_DIR), which is definitely not
what we usually do for host  packages. The expected output of a host
package is to install something in $(HOST_DIR), so that it can later be
used (e.g. by another package, or by a post-build/post-image script)

Here's what I think should be done:

    ZYNQ_BOOT_BIN_VERSION = xilinx-v2015.1
    ZYNQ_BOOT_BIN_SOURCE = zynq-boot-bin.py
    ZYNQ_BOOT_BIN_SITE = https://raw.githubusercontent.com/Xilinx/u-boot-xlnx/$(ZYNQ_BOOT_BIN_VERSION)/tools
    ZYNQ_BOOT_BIN_LICENSE = GPLv3+
    # No license file, license in file itself

    HOST_ZYNQ_BOOT_BIN_DEPENDENCIES = host-python

    define HOST_ZYNQ_BOOT_BIN_INSTALL_CMDS
        @cp $(DL_DIR)/$(ZYNQ_BOOT_BIN_SOURCE) \
        $(HOST_DIR)/usr/bin/$(ZYNQ_BOOT_BIN_SOURCE)
    endef

    $(eval $(hhost-generic-package))

And then in the board README file, state something along the lines:

    ---8<---
    To finalise the boot device, run the following command:

      $ ./output/host/usr/bin/zynq-boot-bin.py \
            -u output/images/boot.bin \
            -o /path/to/the/boot-stuff
    ---8<---

(you get the idea)

Note: that's what we do for the Raspberry Pi, for example, where we
install the 'mkknlimg' utility in $(HOST_DIR) and tell the user how to
use it in the board readme file:

    ---8<---
    The kernel image must be marked with a special header so that the
    bootloader of the RaspberryPi knows it supports Device Tree:

      $ ./output/host/usr/bin/mkknlimg output/images/zImage \
                                       /mnt/mountpointboot/zImage
    ---8<---

Regards,
Yann E. MORIN.

On 07/03/15 19:33, Yann E. MORIN wrote:
> Jan, All,
> 
> On 2015-06-23 14:49 +0200, Jan Viktorin spake thusly:
>> From: Jan Viktorin <viktorin@rehivetech.com>
>>
>> The package creates file images/boot.bin to boot
>> Xilinx Zynq based boards. It might not work with
>> U-Boot older then 2015.07.
>>
>> The script zynq-boot-bin.py is contained in the
>> Xilinx repository of U-Boot (it is not in upstream).
>>
>> Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
> [--SNIP--]
>> diff --git a/package/zynq-boot-bin/zynq-boot-bin.mk b/package/zynq-boot-bin/zynq-boot-bin.mk
>> new file mode 100644
>> index 0000000..aff4593
>> --- /dev/null
>> +++ b/package/zynq-boot-bin/zynq-boot-bin.mk
>> @@ -0,0 +1,24 @@
>> +################################################################################
>> +#
>> +# zynq-boot-bin
>> +#
>> +################################################################################
>> +
>> +ZYNQ_BOOT_BIN_VERSION = xilinx-v2015.1
>> +ZYNQ_BOOT_BIN_SOURCE = zynq-boot-bin.py
>> +ZYNQ_BOOT_BIN_SITE = https://raw.githubusercontent.com/Xilinx/u-boot-xlnx/$(ZYNQ_BOOT_BIN_VERSION)/tools
> 
> Missing licensing information:
>     ZYNQ_BOOT_BIN_LICENSE = foo license...
>     ZYNQ_BOOT_BIN_LICENSE_FILES = License-file
> 
>> +HOST_ZYNQ_BOOT_BIN_INSTALL_STAGING = NO
>> +HOST_ZYNQ_BOOT_BIN_INSTALL_IMAGES = YES
> 
> Since this is a host-only package, you need not specify either;
>   - install_staging already defaults to no,
>   - both are anyway only valid for target packages.

 But actually, it's not a host package, it's a target package. Took me some time
to realize that however :-) See below.

> 
>> +HOST_ZYNQ_BOOT_BIN_DEPENDENCIES = uboot
>> +
>> +define HOST_ZYNQ_BOOT_BIN_EXTRACT_CMDS
>> +	@cp $(DL_DIR)/$(ZYNQ_BOOT_BIN_SOURCE) $(@D)
>> +endef
>> +
>> +define HOST_ZYNQ_BOOT_BIN_BUILD_CMDS
>> +	@env python2 $(@D)/zynq-boot-bin.py -o $(BINARIES_DIR)/boot.bin \
> 
> That mught be an indication that it should depend on host-python, no?

 Actually, no, we actually require a system-python to exist. I think it also
needs to be python2 though we don't check for that. And to be honest, I have no
idea why we require it...

 But I certainly wouldn't like to have to build a host-python just to be able to
build the boot loader... So I'm glad there's no dependency on host-python.

> 
>> +		-u $(BINARIES_DIR)/$(notdir $(call qstrip,$(BR2_TARGET_UBOOT_SPL_NAME)))
>> +endef
> 
> Although what you wrote does work, it is not absolutely correct: the
> build commands should just really build, not install anything in the
> output directories.

 +1.

> 
> You should generate the files in the package build directory, and
> provide a command that does the install (even if it is just copying the
> generated files).
> 
>> +$(eval $(host-generic-package))
> 
> But, then since you install in $(BINARIES_DIR), which is definitely not
> what we usually do for host  packages. The expected output of a host
> package is to install something in $(HOST_DIR), so that it can later be
> used (e.g. by another package, or by a post-build/post-image script)
> 
> Here's what I think should be done:
> 
>     ZYNQ_BOOT_BIN_VERSION = xilinx-v2015.1
>     ZYNQ_BOOT_BIN_SOURCE = zynq-boot-bin.py
>     ZYNQ_BOOT_BIN_SITE = https://raw.githubusercontent.com/Xilinx/u-boot-xlnx/$(ZYNQ_BOOT_BIN_VERSION)/tools
>     ZYNQ_BOOT_BIN_LICENSE = GPLv3+
>     # No license file, license in file itself
> 
>     HOST_ZYNQ_BOOT_BIN_DEPENDENCIES = host-python
> 
>     define HOST_ZYNQ_BOOT_BIN_INSTALL_CMDS
>         @cp $(DL_DIR)/$(ZYNQ_BOOT_BIN_SOURCE) \
>         $(HOST_DIR)/usr/bin/$(ZYNQ_BOOT_BIN_SOURCE)
>     endef
> 
>     $(eval $(hhost-generic-package))
> 
> And then in the board README file, state something along the lines:
> 
>     ---8<---
>     To finalise the boot device, run the following command:
> 
>       $ ./output/host/usr/bin/zynq-boot-bin.py \
>             -u output/images/boot.bin \
>             -o /path/to/the/boot-stuff
>     ---8<---
> 
> (you get the idea)

 That's what Jan originally had, but I told him to do it this way :-)

 You can view zynq-boot-bin as something which really should be part of uboot.
The only point of this "program" is to create the bootloader. It will never be
applied on anything except the bootloader. It doesn't need any additional
configuration or command line arguments. So it would be quite pointless to burde
the user with writing that stuff in a post-build script.

 Perhaps, however, it should go into the boot/ directory instead of packages. It
is, after all, a pre-bootloader, like at91bootstrap.

> 
> Note: that's what we do for the Raspberry Pi, for example, where we
> install the 'mkknlimg' utility in $(HOST_DIR) and tell the user how to
> use it in the board readme file:

 I think the same approach could be taken there. Though I can't say I understand
much of all the hoops you have to jump through to boot an RPi.

 Regards,
 Arnout

> 
>     ---8<---
>     The kernel image must be marked with a special header so that the
>     bootloader of the RaspberryPi knows it supports Device Tree:
> 
>       $ ./output/host/usr/bin/mkknlimg output/images/zImage \
>                                        /mnt/mountpointboot/zImage
>     ---8<---
> 
> Regards,
> Yann E. MORIN.
>

Arnout, Jan, All,

On 2015-07-03 22:00 +0200, Arnout Vandecappelle spake thusly:
> On 07/03/15 19:33, Yann E. MORIN wrote:
> > On 2015-06-23 14:49 +0200, Jan Viktorin spake thusly:
[--SNIP--]
> > Since this is a host-only package, you need not specify either;
> >   - install_staging already defaults to no,
> >   - both are anyway only valid for target packages.
> 
>  But actually, it's not a host package, it's a target package. Took me some time
> to realize that however :-) See below.

Still, I am not sure, see below. ;-)

[--SNIP--]
> > That mught be an indication that it should depend on host-python, no?
> 
>  Actually, no, we actually require a system-python to exist. I think it also
> needs to be python2 though we don't check for that. And to be honest, I have no
> idea why we require it...

I don't know why we require it for packages, but we at least need it for
the manual.

I was added way back in 2010 byy Thomas P. to fix #1531.

>  But I certainly wouldn't like to have to build a host-python just to be able to
> build the boot loader... So I'm glad there's no dependency on host-python.

Agreed.

> > Here's what I think should be done:
[--SNIP--]

>  That's what Jan originally had, but I told him to do it this way :-)
> 
>  You can view zynq-boot-bin as something which really should be part of uboot.
> The only point of this "program" is to create the bootloader. It will never be
> applied on anything except the bootloader. It doesn't need any additional
> configuration or command line arguments. So it would be quite pointless to burde
> the user with writing that stuff in a post-build script.
> 
>  Perhaps, however, it should go into the boot/ directory instead of packages. It
> is, after all, a pre-bootloader, like at91bootstrap.

Right, that would be a better location.

Still, I believe we should handle this tool as a host tool, to support
users that build their bootloader outside of Buildroot (we already
install similar tools for this reason).

> > Note: that's what we do for the Raspberry Pi, for example, where we
> > install the 'mkknlimg' utility in $(HOST_DIR) and tell the user how to
> > use it in the board readme file:
> 
>  I think the same approach could be taken there.

I respectfully disagree. ;-)

rpi-firmware installs a utility to add a header (really, a trailler) to
the kernel image. Since the user can build his kernel outside Buildroot,
we still want to leave him/her the possibility to tag the kernel
properly; hence we install this utility in $(HOST_DIR), either when
doing the SDcard manually, or from a post-image script.

I believe we are here in a similar situation with host-zynq-boot-bin.

However, we might be a bit more helpful here, so we have a way to
automatically run those commands in a sane, generic way, like we have
with TARGET_FINALIZE_HOOKS for target-finalize, but this time for
images.

Note: we might _technically_ be able tore-use TARGET_FINALIZE_HOOKS,
but I'm a bit uneasy to hijack it to deal with images, when it was meant
to deal with the content of $(TARGET_DIR).

> Though I can't say I understand
> much of all the hoops you have to jump through to boot an RPi.

Well, it's pretty similar to the zedboard case (from what I see in the
zedboard readme):
  - a first partition, FAT16 or FAT32, with a bunch of files in there:
    - the GPU blob, its config file, the CPU init blob
    - the kernel, its command line (in a text file)
  - a second partition with the rootfs

Regards,
Yann E. MORIN.

Hello Arnout, Yann,

I am glad you are interested in this little feature. My original
goal was to deliver a simple out-of-the-box mechanism to easily
create a bootable system for Zedboard without any additional
steps and with the ability to turn it off easily if necessary.

I do not understand, how should this script be treated as
a bootloader stuff. I see it just as a helper host tool like the
uboot-tools are (a common host package). However, uboot-tools
is integrated quite deeply, it creates uImage (done by Kernel
build-system) and especially root file-system (done by Buildroot).
I would expect that zynq-boot-bin.py works in a similar way.

I have no clue about the TARGET_FINALIZE_HOOKS but it sounds
promising.

What I find quite a good idea is to use a post-<something>
script. But for that purpose, I thinks a working script in
the boards/avnet/zedboard exactly for this purpose should be
provided together with a preset inside the zedboard_defconfig
to use it as default. This creates an out-of-the-box working
configuration that is easily customizable. But what about other
Zynq-based boards (well, there is no one there at the moment,
but...)? Could they share the same script?

Another point that was omitted here (but it is described in the
readme.txt) is that the SPL searchs for uboot-dtb.img while booting.
This file is however not installed in the images directory. Instead,
user gets the u-boot.img that does not work together with the SPL
(at least for me). This is confusing... First, I do not get the working
SPL automatically, second, I do not get the right U-Boot image. From
this point of view, I'd like the original patch-based implementation :).
Is this also an issue for other boards?

I am about to:

* remove the _INSTALL_STAGING, _INSTALL_IMAGES settings,
* specify the license,
* put there the EXTRACT_CMDS to avoid failure when trying to extract
  the zynq-boot-bin.py as an tar archive (is this correct assumption?)
* put there the INSTALL_CMDS to install the zynq-boot-bin.py into
  HOST_DIR

The last step is not clear to me. I also found a kind of inspiration in
fs/cpio:

 34 $(BINARIES_DIR)/rootfs.cpio.uboot: $(BINARIES_DIR)/rootfs.cpio host-uboot-tools
 35         $(MKIMAGE) -A $(MKIMAGE_ARCH) -T ramdisk \
 36                 -C none -d $<$(ROOTFS_CPIO_COMPRESS_EXT) $@

Would it be possible to define similar rules in uboot.mk?

 $(BINARIES_DIR)/boot.bin: host-zynq-boot-bin
     python2 $(HOST_DIR)/usr/bin/zynq-boot-bin.py \
         -u $(@D)/spl/u-boot-spl.bin -o $@

Regards,
Jan

On Fri, 3 Jul 2015 23:51:04 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> Arnout, Jan, All,
> 
> On 2015-07-03 22:00 +0200, Arnout Vandecappelle spake thusly:
> > On 07/03/15 19:33, Yann E. MORIN wrote:
> > > On 2015-06-23 14:49 +0200, Jan Viktorin spake thusly:
> [--SNIP--]
> > > Since this is a host-only package, you need not specify either;
> > >   - install_staging already defaults to no,
> > >   - both are anyway only valid for target packages.
> > 
> >  But actually, it's not a host package, it's a target package. Took
> > me some time to realize that however :-) See below.
> 
> Still, I am not sure, see below. ;-)
> 
> [--SNIP--]
> > > That mught be an indication that it should depend on host-python,
> > > no?
> > 
> >  Actually, no, we actually require a system-python to exist. I
> > think it also needs to be python2 though we don't check for that.
> > And to be honest, I have no idea why we require it...
> 
> I don't know why we require it for packages, but we at least need it
> for the manual.
> 
> I was added way back in 2010 byy Thomas P. to fix #1531.
> 
> >  But I certainly wouldn't like to have to build a host-python just
> > to be able to build the boot loader... So I'm glad there's no
> > dependency on host-python.
> 
> Agreed.
> 
> > > Here's what I think should be done:
> [--SNIP--]
> 
> >  That's what Jan originally had, but I told him to do it this
> > way :-)
> > 
> >  You can view zynq-boot-bin as something which really should be
> > part of uboot. The only point of this "program" is to create the
> > bootloader. It will never be applied on anything except the
> > bootloader. It doesn't need any additional configuration or command
> > line arguments. So it would be quite pointless to burde the user
> > with writing that stuff in a post-build script.
> > 
> >  Perhaps, however, it should go into the boot/ directory instead of
> > packages. It is, after all, a pre-bootloader, like at91bootstrap.
> 
> Right, that would be a better location.
> 
> Still, I believe we should handle this tool as a host tool, to support
> users that build their bootloader outside of Buildroot (we already
> install similar tools for this reason).
> 
> > > Note: that's what we do for the Raspberry Pi, for example, where
> > > we install the 'mkknlimg' utility in $(HOST_DIR) and tell the
> > > user how to use it in the board readme file:
> > 
> >  I think the same approach could be taken there.
> 
> I respectfully disagree. ;-)
> 
> rpi-firmware installs a utility to add a header (really, a trailler)
> to the kernel image. Since the user can build his kernel outside
> Buildroot, we still want to leave him/her the possibility to tag the
> kernel properly; hence we install this utility in $(HOST_DIR), either
> when doing the SDcard manually, or from a post-image script.
> 
> I believe we are here in a similar situation with host-zynq-boot-bin.
> 
> However, we might be a bit more helpful here, so we have a way to
> automatically run those commands in a sane, generic way, like we have
> with TARGET_FINALIZE_HOOKS for target-finalize, but this time for
> images.
> 
> Note: we might _technically_ be able tore-use TARGET_FINALIZE_HOOKS,
> but I'm a bit uneasy to hijack it to deal with images, when it was
> meant to deal with the content of $(TARGET_DIR).
> 
> > Though I can't say I understand
> > much of all the hoops you have to jump through to boot an RPi.
> 
> Well, it's pretty similar to the zedboard case (from what I see in the
> zedboard readme):
>   - a first partition, FAT16 or FAT32, with a bunch of files in there:
>     - the GPU blob, its config file, the CPU init blob
>     - the kernel, its command line (in a text file)
>   - a second partition with the rootfs
> 
> Regards,
> Yann E. MORIN.
>

Dear Jan Viktorin,

On Tue, 23 Jun 2015 14:49:10 +0200, Jan Viktorin wrote:
> From: Jan Viktorin <viktorin@rehivetech.com>
> 
> The package creates file images/boot.bin to boot
> Xilinx Zynq based boards. It might not work with
> U-Boot older then 2015.07.
> 
> The script zynq-boot-bin.py is contained in the
> Xilinx repository of U-Boot (it is not in upstream).
> 
> Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>

After reading the discussion with Arnout and Yann, here is what I'd
personally prefer to see for this:

 * A host-zynq-boot-bin package, which only downloads and installs the
   Python script to $(HOST_DIR)/usr/bin. If the script is Python 2 only
   then you must make it depend on host-python, because the system
   Python can be either Python 2 or 3. If however, the script is Python
   2 and Python 3 compatible, there is no need to add a host-python
   dependency, because we can use the system provided Python
   interpreter.

 * One of the two following solutions:

   - An extension of the U-Boot Config.in + uboot.mk to optionally
     generated a Zynq image. It would add host-zynq-boot-bin in the
     dependencies of U-Boot, and call the Python script at the right
     time. Something along the lines of:

ifeq ($(BR2_TARGET_UBOOT_ZYNQ_IMAGE),y)
define UBOOT_GENERATE_ZYNQ_IMAGE
	$(HOST_DIR)/usr/bin/python2 $(HOST_DIR)/usr/bin/zynq-..py -o $(BINARIES_DIR)/...
endef
UBOOT_DEPENDENCIES += host-zynq-boot-bin
UBOOT_POST_INSTALL_IMAGES_HOOKS += UBOOT_GENERATE_ZYNQ_IMAGE
endif

   - Just not do anything special in U-Boot, and add an entry in
     menuconfig to enable the host-zynq-boot-bin package, and in your
     board configuration, write a post-build script that generates the
     final image.

Thomas

Hello all,

here follows another version of the patch series. I have rewritten it
based on the previous discussion with Yann, Arnout and Thomas.

The patch 1 is unrelated, I did not know whether to post it alone
or if it is OK to put it here...

The host-zynq-boot-bin is just "download & install" now.

I've added a new output format of U-Boot to generate u-boot-dtb.img which
is booted by the SPL. The generation of the BOOT.BIN file is moved into
uboot.mk as suggested by Thomas. I am little bit unsure about the config
BR2_TARGET_UBOOT_ZYNQ_IMAGE (the depends on/select). To enable the BOOT.BIN
generation, the user must set the dtb.img format and enable SPL. However,
the zedboard_defconfig does it so it might be OK.

The zedboard related changes are slightly modified but almost the same.

Regards
Jan Viktorin


Jan Viktorin (7):
  docs/manual: Fix trivial typo
  host-zynq-boot-bin: new package
  boot/uboot: Add support for dtb.img format
  boot/uboot: Generate BOOT.BIN file when building for Xilinx Zynq
  zedboard: Generate BOOT.BIN automatically
  zedboard: Patch default U-Boot environment for zedboard
  zedboard: Update readme.txt to reflect BOOT.BIN generation

 board/avnet/zedboard/readme.txt                    | 84 ++++++++++------------
 ...eate-zedboard-specific-U-Boot-environment.patch | 46 ++++++++++++
 boot/uboot/Config.in                               | 16 +++++
 boot/uboot/uboot.mk                                | 12 ++++
 configs/zedboard_defconfig                         |  9 +--
 docs/manual/adding-packages-python.txt             |  2 +-
 package/Config.in.host                             |  1 +
 package/zynq-boot-bin/Config.in.host               |  8 +++
 package/zynq-boot-bin/zynq-boot-bin.hash           |  2 +
 package/zynq-boot-bin/zynq-boot-bin.mk             | 22 ++++++
 10 files changed, 151 insertions(+), 51 deletions(-)
 create mode 100644 board/avnet/zedboard/uboot/0001-zynq-Create-zedboard-specific-U-Boot-environment.patch
 create mode 100644 package/zynq-boot-bin/Config.in.host
 create mode 100644 package/zynq-boot-bin/zynq-boot-bin.hash
 create mode 100644 package/zynq-boot-bin/zynq-boot-bin.mk