Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

add Pine64 support #140

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

add Pine64 support #140

wants to merge 2 commits into from

Conversation

Hades32
Copy link

@Hades32 Hades32 commented Jul 23, 2021

Pine64 meaning the original Pine A64 (not 64-LTS, SoPine64, or Rock64)

@resin-jenkins
Copy link

Can one of the admins verify this patch?

@Hades32 Hades32 force-pushed the pine64 branch 2 times, most recently from eca7bb2 to 9a4c8b8 Compare July 25, 2021 13:29
@Hades32 Hades32 requested a review from klutchell July 25, 2021 13:32
@klutchell
Copy link
Contributor

@resin-jenkins add to whitelist

@klutchell
Copy link
Contributor

balena device repos such as this require an odd commit message

  • change-type is not required since it gets its version from meta-balena
  • changelog-entry is required I think, but I don't recall why it doesn't use the commit title like most repos

@Hades32
Copy link
Author

Hades32 commented Jul 27, 2021

@klutchell jenkins didn't even try the new machine type. Is there something I'm missing?

@klutchell
Copy link
Contributor

We would need to set up a new Jenkins job for this device type, we can ask (at)devices for help if we get to that point.

I can try building it locally first. Are you still getting build errors?

@Hades32
Copy link
Author

Hades32 commented Jul 27, 2021

@klutchell I tried it twice and it's definitely a permanent error and I'm at a point where I don't know what to do next. So please try it :)

klutchell
klutchell reviewed Jul 27, 2021
View reviewed changes
README.md Outdated Show resolved Hide resolved
@klutchell
Copy link
Contributor

klutchell commented Jul 27, 2021 •
edited
Loading

Confirmed I see the same build error, not enough space in the boot partition.

ping64-plus

NOTE: resin-boot: FAT overhead 962 sectors, data 61396 sectors, largest file 60110 sectors, boot size 81920 sectors.
ERROR: resin-boot: Not enough space for atomic copy operations.

bananapi-m1-plus

NOTE: resin-boot: FAT overhead 280 sectors, data 17768 sectors, largest file 16712 sectors, boot size 81920 sectors.

@klutchell
Copy link
Contributor

pine64-plus

30M     build/tmp/work/pine64_plus-poky-linux/balena-image/1.0-r0/rootfs/resin-boot/Image
4.0K    build/tmp/work/pine64_plus-poky-linux/balena-image/1.0-r0/rootfs/resin-boot/balena-image
4.0K    build/tmp/work/pine64_plus-poky-linux/balena-image/1.0-r0/rootfs/resin-boot/balenaos.fingerprint
4.0K    build/tmp/work/pine64_plus-poky-linux/balena-image/1.0-r0/rootfs/resin-boot/config.json
4.0K    build/tmp/work/pine64_plus-poky-linux/balena-image/1.0-r0/rootfs/resin-boot/device-type.json
40K     build/tmp/work/pine64_plus-poky-linux/balena-image/1.0-r0/rootfs/resin-boot/dtb
0       build/tmp/work/pine64_plus-poky-linux/balena-image/1.0-r0/rootfs/resin-boot/extra_uEnv.txt
4.0K    build/tmp/work/pine64_plus-poky-linux/balena-image/1.0-r0/rootfs/resin-boot/image-version-info
4.0K    build/tmp/work/pine64_plus-poky-linux/balena-image/1.0-r0/rootfs/resin-boot/os-release
20K     build/tmp/work/pine64_plus-poky-linux/balena-image/1.0-r0/rootfs/resin-boot/splash
12K     build/tmp/work/pine64_plus-poky-linux/balena-image/1.0-r0/rootfs/resin-boot/system-connections
580K    build/tmp/work/pine64_plus-poky-linux/balena-image/1.0-r0/rootfs/resin-boot/u-boot-pine64-plus.bin
30M     total

bananapi-m1-plus

4.0K    build/tmp/work/bananapi_m1_plus-poky-linux-gnueabi/balena-image/1.0-r0/rootfs/resin-boot/balena-image
4.0K    build/tmp/work/bananapi_m1_plus-poky-linux-gnueabi/balena-image/1.0-r0/rootfs/resin-boot/balenaos.fingerprint
4.0K    build/tmp/work/bananapi_m1_plus-poky-linux-gnueabi/balena-image/1.0-r0/rootfs/resin-boot/config.json
4.0K    build/tmp/work/bananapi_m1_plus-poky-linux-gnueabi/balena-image/1.0-r0/rootfs/resin-boot/device-type.json
48K     build/tmp/work/bananapi_m1_plus-poky-linux-gnueabi/balena-image/1.0-r0/rootfs/resin-boot/dtb
0       build/tmp/work/bananapi_m1_plus-poky-linux-gnueabi/balena-image/1.0-r0/rootfs/resin-boot/extra_uEnv.txt
4.0K    build/tmp/work/bananapi_m1_plus-poky-linux-gnueabi/balena-image/1.0-r0/rootfs/resin-boot/image-version-info
4.0K    build/tmp/work/bananapi_m1_plus-poky-linux-gnueabi/balena-image/1.0-r0/rootfs/resin-boot/os-release
20K     build/tmp/work/bananapi_m1_plus-poky-linux-gnueabi/balena-image/1.0-r0/rootfs/resin-boot/splash
12K     build/tmp/work/bananapi_m1_plus-poky-linux-gnueabi/balena-image/1.0-r0/rootfs/resin-boot/system-connections
456K    build/tmp/work/bananapi_m1_plus-poky-linux-gnueabi/balena-image/1.0-r0/rootfs/resin-boot/u-boot-sunxi-with-spl.bin
8.2M    build/tmp/work/bananapi_m1_plus-poky-linux-gnueabi/balena-image/1.0-r0/rootfs/resin-boot/uImage
8.8M    total

Looks like that 30M Image is the problem, vs the 8.2M uImage used for the other platforms.

@Hades32
Copy link
Author

Hades32 commented Jul 28, 2021

@klutchell hmm, yeah and that seems to be because of aarch64. layers/meta-sunxi/conf/machine/include/sunxi.inc uses uImage whereas layers/meta-sunxi/conf/machine/include/sunxi64.inc uses Image.
I don't know what the difference is, but I'll try to build with KERNEL_IMAGETYPE = "uImage"

@Hades32
Copy link
Author

Hades32 commented Jul 29, 2021 •
edited
Loading

uImage doesn't seem to be an option:

make[1]: *** No rule to make target 'uImage'.  Stop.

I had to specify it via -a KERNEL_IMAGETYPE=... as putting it in the machine/pine.conf had no effect for some reason

add Pinei A64+ support
abcbf6b 
Change-type: minor
Signed-off-by: Martin Rauscher <[email protected]>
@Hades32
Copy link
Author

Hades32 commented Jul 29, 2021 •
edited
Loading

@klutchell I managed to get a build with -a KERNEL_IMAGETYPE=Image.gz! I'll try it out on the weekend.

I updated the PR accordingly, but I only got the parameter working when passing it on the command line. Do you know what I'm doing wrong?

It's weird as https://github.com/balena-os/balena-generic/blob/master/layers/meta-balena-generic/conf/machine/generic-aarch64.conf#L12 does the exact same thing... Maybe I just need to do a clean build...

Edit: What is our general approach to kernel images? I read, there is also a FIT image type

add Pine A64+ to readme
0d4e7f3 
Changelog-entry: Add Pine A64+ support
Change-type: patch
Signed-off-by: Martin Rauscher <[email protected]>
@klutchell
Copy link
Contributor

I'm not aware of us using the FIT image type anywhere, Image.gz is likely correct.

Setting KERNEL_IMAGETYPE in the machine conf is definitely the correct place.

However I just noticed that your pine64-plus.conf has the same name as an existing one in meta-sunxi, which is maybe where you got yours from.

Unfortunately machine .conf files of the same name will not be respected properly so if we want to override any values of the upstream one we'll need a new filename.

I tried setting KERNEL_IMAGETYPE directly in a few recipes like balena-image.inc and linux-mainline_%.bbappend but there are too many recipes that use that value, and we would need to add new bbappend files for many of them. Everything expects KERNEL_IMAGETYPE to be global.

@Hades32
Copy link
Author

Hades32 commented Jul 29, 2021

ahh, I see, thanks @klutchell! That sounds like something that would happen alle the time...?

What's the best way forward then? Should I prefix it with balena- or make a name that's just slightly different like pine-a64-plus?

@klutchell
Copy link
Contributor

Probably something like pine-a64-plus unless @floion or @acostach has encountered this before and has a better idea.

Q. How do we override a machine var like KERNEL_IMAGETYPE if the target machine already exists upstream with a different value?

@Hades32
Copy link
Author

Hades32 commented Jul 31, 2021 •
edited
Loading

So, I tried the image and absolutely nothing happened. I don't have a UART connector to try to get any debug logs, but after reading https://github.com/u-boot/u-boot/blob/master/board/sunxi/README.sunxi64 I guess getting u-boot running (including the switch from 32bit to 64bit mode) is a little more involved...

Looks relevant as well: https://github.com/alistair23/meta-pine64/blob/master/recipes-bsp/u-boot/u-boot_%25.bbappend
and https://github.com/alistair23/meta-pine64/blob/master/wic/pine64-bsp-image.wks

@klutchell
Copy link
Contributor

I think you'll struggle without a UART or HDMI monitor to view boot logs.

Are you sure that u-boot-pine64-plus.bin is the correct bootloader file? It seems most devices use u-boot-sunxi-with-spl.bin but maybe the change was intentional?

@Hades32
Copy link
Author

Hades32 commented Aug 4, 2021

@klutchell I connected HDMI, but nothing was happening. I think that file was used because it's the only aarch64 device. But I can try with the other one

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@klutchell klutchell klutchell left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@Hades32 @resin-jenkins @klutchell