Added Raspberrypi2 support

[izak]

No description provided.

[mpvader]

Hi Izak, great that you are already got it working! Some questions/remarks:

1. please make pull requests (in case not already done) for meta-victronenergy, instead of linking to a fork on another account
2. why is it necessary to make a separate config for this? The idea behind the configs is that the jethro one should be able to be used to build for rpis and other machines too.
3. is it really necessary to keep a clone, with additional commit, of meta-raspberrypi? Why?

[mpvader]

4. and looks like most that you have in meta-victronenergy-rpi2 should be in meta-victronenergy instead.

[mpvader]

5. I'd expect a raspberrypi2 file here:
   https://github.com/izak/meta-victronenergy/tree/master/meta-bsp/conf/machine (which can then be pulled into the same repo on the victronenergy account).

[izak]

There are still some things about bitbake I don't understand, clearly. I was concerned that just adding it into the jethro configuration would cause the recipes to pollute the ccgx and bbb builds. I want those changes (for example the kernel patches) to only apply to the rpi2 build.

I already made a pull request for meta-victronenergy. It only adds a configuration for simple-upnpd, without which it doesn't build.

I forked meta-raspberrypi because of this issue. The patch the commenter refers to is quite old, yet there is no movement on the issue. How do we deal with something like this, where a fix is needed but it is not making it into upstream?

[mpvader]

Polluting is prevented by having a linux-[machine-name] in meta-bsp and referencing it from the conf files as the preferred virtual/kernel provider.

Yes, we'll take the upnp commit. I'm on holiday and Jeroen has v1.70 as his priority. So things take a little while.

When an additional patch is necessary, we'll clone the repo into github/victronenergy, and make a new branch. So the master branch can be kept up to date with upstream. @jhofstee is the specialist in this.

[izak]

It seems as if this is already taken care of in the meta-raspberrypi layer. So I can just add it into the jethro config then.

[izak]

Also created a pull request into the meta-raspberrypi layer for the kernel config patch.

[mpvader]

Our conf files include some more info than the default one in meta-raspberrypi.

Which serial ports are dedicated vedirect ports for example (none for a raspberrypi ;) so that is a bad example). Just copy that one from meta-raspberrypi and add the other parts that you see in beaglebone.conf and bpp3.conf.

As an example, specify 'headless', as in beaglebone. At least I assume most people will want to run the rpi2 headless. (??)

machine-runtime-config will create /etc/venus/headless. And that will make the GUI / and Remote Console functions initialize with a different set of defaults: Remote Console on LAN enabled, so one can set the thing up without having to buy a proper tv or USB keyboard or adafruit touchscreen. Details here in the GUI run script.

In case adding headless to the machine features breaks the option to add a touchscreen, we could make a separate variable for it that isn't already used in OE.

[izak]

I'll probably close this PR later, then rebase the changes and make a new one. Just keeping this here for now.

[izak]

So this is my present problem. If I copy that machine conf file into the meta-bsp layer, it doesn't work because bitbake finds the one in the meta-raspberrypi layer first. If I change the layer's priority, it still finds it first. If I rename the raspberrypi2.conf file in that layer to force it to find the meta-bsp one first, then it works. So far I have not been able to figure out a way to extend machine configurations. So that leaves me with a few options.

1. Copy the required recipes into our layers and drop the whole meta-raspberrypi layer. That means we have to do everything ourselves, no implicit support for the rpi0 or rpi3 or whatever is added upstream.
2. Give it a new name on our side. Not much better than the first option, you still have to explicitly add support, you don't get it for free.
3. Find out if and how to extend a machine configuration.

Any ideas? I'm leaning towards option 1.

[mpvader]

Well, on 1 and 2: we'll never implicitly get support. There will always be some work required. At the very least some settings in the [machine].conf file.

How much recipes and things do we need to copy over to meta-victronenergy to no longer need meta-raspberrypi? Perhaps it is an idea to try that first? If it is not too much, I'd say yes let's do that.

[izak]

I think it's just two recipes. The one for the kernel, and the one for the firmware. The rest of the recipes in the layer has to do with bluetooth, media players, development stuff (WiringPi etc). So agreed then, I'll go with option 1.

[izak]

In the end, I had to bring over three recipes, and this all went into meta-victronenergy. So I will close this PR shortly. The bits I had to steal:

1. linux-raspberrypi. This simply goes next to linux-ccgx and linux-bbb in the meta-bsp/recipes-kernel/linux directory.
2. linux-firmware. Goes into the same recipes-kernel directory. It simply adds on the broadcom firmware.
3. recipes-bsp/bootfiles. The rpi doesn't have a bootloader and though you can use Das U-boot, it's rather pointless as it creates more work rather than less. The proprietary boot code of the rpi reads kernel7.img from the first FAT partition, and that is that. So the bootfiles recipe builds that bit of the image, and it has no explicit bootloader. I think this needs a rename to indicate more clearly that it's a raspberrypi specific bit.

Then it also needs:

1. Two extra classes: linux-raspberrypi-base.bbclass sdcard_image-rpi.bbclass
2. The raspberrypi2.conf file in conf/machine. I also pulled in the include files from the original layer, but named the directory "raspberrypi2" instead of just "include" as it was in the original layer.

Finally, this repo needs just one change: Add "raspberrypi2" to the machines file.

[jhofstee]

Hello Izak,

On 07-08-16 18:36, Izak Burger wrote:

In the end, I had to bring over three recipes, and this all went into
meta-victronenergy. So I will close this PR shortly. The bits I had to
steal:

linux-raspberrypi. This simply goes next to linux-ccgx and
linux-bbb in the meta-bsp/recipes-kernel/linux directory.

linux-firmware. Goes into the same recipes-kernel directory. It
simply adds on the broadcom firmware.

recipes-bsp/bootfiles. The rpi doesn't have a bootloader and
though you can use Das U-boot (die duikboot), it's rather
pointless as it creates more work rather than less. The
proprietary boot code of the rpi reads kernel7.img from the first
FAT partition, and that is that. So the bootfiles recipe builds
that bit of the image, and it has no explicit bootloader. I think
this needs a rename to indicate more clearly that it's a
raspberrypi specific bit.

Then it also needs:

Two extra classes: linux-raspberrypi-base.bbclass
sdcard_image-rpi.bbclass

The raspberrypi2.conf file in conf/machine. I also pulled in the
include files from the original layer, but named the directory
"raspberrypi2" instead of just "include" as it was in the original
layer.

Finally, this repo needs just one change: Add "raspberrypi2" to the
machines file.

First of all, openembedded has a search function for metas, so you can
figure out who the "upstream" is,
see
https://layers.openembedded.org/layerindex/branch/master/layer/meta-raspberrypi/,
so upstream is
likely http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/log.
But I guess the one you found on github
is a fork of it so likely almost equal. (if you copy recipes please
mention in the commit log where you copied
them from).

We do need u-boot though, I guess, to make updates reliable, since we
have redundant rootfs-es and kernels
and need to be able to switch between them.

Regards,
Jeroen

[izak]

Indeed, https://github.com/agherzan/meta-raspberrypi is simply forked to the yocto project, so it is the same. I mentioned it in the commit log.

I rebased now and made one commit of it. I'm not sure how to integrate u-boot at all. What I've read so far is you "hack" it to use u-boot by copying the bootable image to kernel7.img on the FAT partition of the pi. Then you chainload u-boot (like you chainloaded a linux boot sector from boot.ini on windows NT in the old days). I'll need to figure out how u-boot works on the others to see if we can bridge this divide. Sadly I just don't know enough about it.

For now, here it is. I was at the point of making a pull request, but then I saw your message, and now I need to read up on u-boot first.

https://github.com/izak/meta-victronenergy/tree/rpi-integration

[mpvader]

Don't worry about u-boot for now, lets make the rest work first. Sounds like you are almost there.

Some comments on these lines on the rpi conf file:

# Inputs for machine-conf-runtime recipe
MACHINE_FEATURES += "headless"
VE_MKX_PORT = "/dev/mk2"
VE_VEDIRECT_PORTS = "/dev/ttyAMA0"
VE_RELAYS = ""

Leave VE_MKx_PORT empty. And to prevent the executable from endlessly running on the rpi add something like DAEMONTOOLS_DOWN_raspberrypi2 = "1" to the vecan_mk2 recipe.

There are no real VE.Direct ports on the rpi, right? So leave VE_VEDIRECT_PORTS empty as well. And that might mess up the serial starter script, (might not! I haven't tested it). If it does, fix that here.

[mpvader]

ps on u-boot we have some other experts that I can pull in when necessary

[mpvader]

ps2: the end result will / should be an image that works plug & play with VE.Direct USB devices. Also Fronius inverters and some other things by the way.

And quite soon we'll be able to have plug & play for VE.Bus (Inverters/Quattros) as well. This needs the MK3-USB. The sw developer that is finishing off support for that into Venus will be back in the office from his summer holidays on Wednesday.

[izak]

On u-boot: It seems the BBB and the CCGX use the same setup where /boot is on the first FAT partition, so it might not be THAT different to what I know.

I made the *_PORTS empty and force-pushed it (having rewritten history and all). Using /dev/ttyAMA0 was a little cheeky, it would allow you to tie a vedirect via a level converter to one of the headers of the Rpi. I doubt anyone would ever use it like that. That is to say, the Rpi doesn't have real vedirect ports just like the BBB doesn't have real vedirect ports, but it does have a TTL-level serial port just like the BBB :-)

There is also a fix to serial-starter I can suggest, which I saw some weeks ago, where you don't need to escape the slashes in the TTY_DEV used in the sed command. Been meaning to do that, so now might be a good time to do both... if it breaks.

I'm going to move this discussion to the new pull request then, will link it here.

[izak]

Pull Request is now here.