Yocto BSP for Schneider HMIBSC

[FabioMolinaris]

Hi everyone,

I have an IoT BSC and having some trouble with a samba connection. I've notice that the software preinstalled is pretty old (node-red is 0.20) so I've ashed Schneider for a newer version and they're send me the source code of an even older version (in the "RevisionHistory" file the node-red version is marked as 0.17.5) and the build of this version is not successful.

For the short term I'll be happy to have an image to flash in the SD-card were samba actually works.

In the long run I'd like to have the source code or a guide to make my own image (with Yocto or something else).

Someone has already solve this problem?

Thanks for the patience

[BevanWeiss]

Unfortunately this tends to be the situation with these products from major vendors (like Schneider / Siemens / Rockwell).  They ship with a legacy version of software, and will never get updated, since there's limited financial incentive for them to do such an upgrade.  They will instead release an entirely new product with slightly newer software (but still legacy for the date of release).

For NodeRed, it should be relatively agnostic of the lower level interfaces, so you should be able to upgrade this in the deployed image without too much difficulty (assuming there is some kind of write/modify access to the filesystem).

If you'd like a whole refresh with new linux kernel (likely to help with samba bugs) then this will be much more difficult.

I had a quick Google and couldn't find any reference to a repo or similar with the yocto recipe.  The documentation did imply that the targeted yocto version was already going to be quite old though (https://fccid.io/2AQ63-HMIBSCEA5X/User-Manual/Users-Manual-2-4033379.pdf suggests that it shipped with Yocto 2.1)

You could try to push the GPL terms aspect, and get whatever recipe they have targeting Yocto 2.1 (if you don't have it already), and then just try to modify the base layer to reference Yocto 3.4 (or whatever the HEAD revision is).. that will likely then start a cascade of mismatched dependencies that would be hard work to slog through... but eventually you should get something with updated components.

What aspect of Samba is it that isn't working for you?

Are you sure it's not just a Samba configuration issue?

[FabioMolinaris]

Ok... well any form of update is problematic due to dependency issue, like you said and I've tried to install a new Yocto system using the image published by 96boards (https://www.96boards.org/product/dragonboard410c/) but there are some trouble in the USB peripheral.

The only OS that seem to work is Ubuntu Core

The problem with Samba is the lack of the cifs-utils package so yes, I'm pretty sure is not a configuration problem

[BevanWeiss]

Is the HMIBSC actually based on the 96boards dev board?

I would have expected the source Schneider would have provided would have been the Yocto recipe for the old 2.1 release (or did it not include the recipe files/references?)

It wouldn't surprise me if the USB didn't work due to the HMIBSC using a USB hub / bridge which differs from the 96boards version in some manner (different chip, different memory location.. anything like that would break the default image) it would likely need some device tree modifications for the HMIBSC hardware config.

As you mention, the HMIBSC recipe likely doesn't have the cifs-util 'package' included within the default layers.

You should however be able to wrap the existing recipe as a base recipe for your own custom, and then just add the cifs-util layer (and other dependencies for SAMBA).

As mentioned before, you should be able to just install these dependencies after deployment.  If you SSH or similar into the HMIBSC, and then use either RPM or any available package manager from the Yocto build you should be able to install cifs-util etc as required.  Not as nice if you're going to be building up dozens of this config daily.. but if it's just a one a day kind of thing then you should be able to get such a post-deploy script down pretty easily.

UbuntuCore is definitely going to be a bit heavier than a default Yocto image.  But it's probably the least friction way forward for you.

[FabioMolinaris]

I think is base on a 96boards because in the source that Schneider give me there's a "meta-96boards", a "meta-advantech" and a "meta-qcom-410c".

For the USB it's actually probable what you're saying but it will be nice find somewhere the specifics.

I've tried compile the sources that Schneider give me but a lot of package are no longer available and the build is not successful, so I've give up on the idea of modify that by adding the cifs-util layer. And install package by rpm or apt is not successful because it can't find any package (I think the repository are no longer up).

[BevanWeiss]

rpm / apt will indeed be quite tricky.  As you mention, the originally configured repositories may now be defunct.

And even if you changed your source list to have up to date repositories available, they would likely not suit the customised distribution (perhaps even the architecture.. unsure if it's AArch64 based, or such.. the Dragon Board seems to be.. I would have expected an x86 based board honestly.. with an Atom or low end Celeron.. but I guess ARM are taking over this space)

You could possibly install dev tools for the distro in question and then try building cifs-utils from scratch (but outside of the Yocto build process).  Although this also sounds quite painful.

What's the licence notice for the files provided by Schneider?  If GPL or similar, could you post them up on Github?

[BevanWeiss]

For the USB stuff.. you'd want to try to find the further down the chain that Schneider provided, and identify either a dtbi or a dtbo file that references the USB controller.  Unfortunately there are numerous other ways of also introducing the USB controller to the kernel, so it might not quite be this straight forward (and given the way Yocto stacks layers, it may still not even be this easy, since the dtbi/dtbo or other method may come in via any other layer).

[FabioMolinaris]

The x86 based board arrive with Windows installed on.

I really don't want to compile and add old stuff on top on an old base. If I get all the component ad can build all the OS with updated package, otherwise no.

I don't know the Schneider policy and license (I think is GPL just because I haven't found anything that says differently). But I've saw the "schneider-electric.app.box" link in other post so I think I can post this in here https://schneider-electric.app.box.com/s/s2df0hz11xv2rhp8wdeo407z19ll0tub (if I can't maybe an admin will intervene)

[BevanWeiss]

I'll have a quick look at it over the next few days and see what I can work out in the source.

[BevanWeiss]

I've had a play around with this, and it's very painful.

So... it appears that there's a bunch of bit-rot that has set in.

I essentially started from this, which did at least let me retrieve a source tree

repo init -u https://github.com/ADVANTECH-Corp/oe-rpb-manifest.git -b krogoth -m 410cLBV1090.xml

Unfortunately this is then where things started to go badly...

The M4 library doesn't like to build with recent gcc, and throws errors about fseek, freadahead etc not being defined, and that I should define them for the platform.

I found some patches that fixed this for M4 1.4.18, but I only had M4 1.4.17 locally, and the fpending.c file content wasn't a good match (so there wasn't a sensible patch to get it compiling).

This is likely the same compile errors that you came upon.

Using their docker image, or an older Ubuntu distribution (perhaps the 14.04 mentioned in the PDF) might have worked here.

It does indeed seem that the HMIBSC is just based on the Advantech rsb-4760 (https://www.advantech.com/products/single_board_computer/rsb-4760/mod_ae673173-8057-497b-82ef-46743a...) which must also be reasonably similar to the 96boards dragonboard 410c.  Hence why the 96boards references were through the Schneider stuff.  Schneider obviously just licence the Advantech HMIBSC and rebranded it.

Using this
https://github.com/96boards/oe-rpb-manifest/tree/dunfell
I've been able to get a build progressing quite well however, using the dragonboard 410c and weston image.

I don't have the HMIBSC to test out the finished image, but it might be a worthwhile starting point.

If it works straight away it would be a win, if it doesn't, then you could start looking a little closer at the differences between the Advantech RSB-4760 layers and the 96boards dragonboard 410c layers.

[FabioMolinaris]

Yes... the pain... I remember that.

During my experiment I was able to build the Advantech one, I've also found the rsb-4760 (I don't remember how, probably by reading some source file).

Unfortunately I wasn't able to boot via SD Card with the Advantech image on it, I've tried to fastboot the /rootfs and still no success. I haven't fastboot the /boot because I don't wanna make a brick of my IoT.

[Enriba]

Hello everybody,

Schneider gave me the link to the latest version of Yocto BSP!

but...

I started the build and got the same results as the previous version: packages not found and various errors.

If you want try it yourself this is the link to the latest version:

https://schneider-electric.app.box.com/s/aqlzs77ay29kir54j76dz24ct9wfwtci

[FabioMolinaris · Accepted solution]

I've found this guide http://ess-wiki.advantech.com.tw/view/IoTGateway/BSP/Linux/APQ8016/BSP_User_Guide_V1#Flash_Pre-built... that contains this link https://www.dropbox.com/sh/6qgkg4m4k91uo7j/AAA_PRO4TthMPZL1jk9hklyCa/2020-02-13?dl=0&subfolder_nav_t... and take the "sd_installer.img" file, flash into the SDcard and it just work.

I count this as a solution (even if is not provided by Schneider)