Raspberry PI Compute Module 4 Baseboard was designed in KiCad

See:

https://www.raspberrypi.org/products/compute-module-4-io-board/

image

Does anyone know what features in the unreleased version they are using not present in the released version?

This seems like a great development and shows that the rPI organization is serious about enabling designers to use their new module.

1 Like

Isn’t the answer in the text you quoted?

Rephrased my question to:

Does anyone know what features in the unreleased version they are using not present in the released version?

:slight_smile:

O god, I just noticed they are advocating users install nightlies. That is terrible or great for the new bug testers for the v6 release.

Are nightly releases available for Linux, or do you have to build from source?

Yeah I’m not super impressed with them doing the design in nightlies (as far as I can tell, they didn’t make use of any new features that would have required nightlies) and then releasing it publicly. Nobody should be forced into using nightlies this way.

1 Like

Sure,
http://ppa.launchpad.net/kicad/kicad-dev-nightly/ubuntu/

Is there anything like appimage, or just a tarball of binaries? I run Arch Linux.

Sorry, I don’t know whether there is or not an appimage for the nighties.

I’m building Arch Linux nightlies every 2-3 days. These are somewhat more optimized than normal builds. LTO & Clear Linux CXXFLAGS and you’ll have to have an Intel Core iX-6XXX (Haswell) or newer. If that fits your bill I can see if I can host the repo somewhere. Try this recent build if you like:

http://rbts.co/download/kicad-git-6.0.0~r18332.06bf7943b7-1-x86_64.pkg.tar.zst
http://rbts.co/download/kicad-git-6.0.0~r18332.06bf7943b7-1-x86_64.pkg.tar.zst.sig

1 Like

You can use makepkg to build the latest nighty from aur:
https://aur.archlinux.org/packages/kicad-git/

I can send you this version, build on my machine:
kicad-git-r18309.6cbe2131a-1-x86_64.pkg.tar (160MB)

Cedric, can you post a build online? I’d love to check why my packages are 25MB on average vs 160MB for yours

I recommend agaisnt calling it 6.0.0. We call it 5.99 for a reason to avoid any and all conflicts once we do actually release 6.0, nor to have users call it 6.0 falsely in bug reports and posting. It’s not 6.0 until the first release candidate is announced :smiley:

2 Likes

It’s auto-generated:

pkgver() {
  cd "${srcdir}/${pkgname}"
  if [ -n ${_pkgver} ]; then
    echo $(git tag | egrep -o '^[0-9]\.[0-9]\.[0-9]' | sort -V | tail -n 1)~$(printf "r%s.%s" "$(git rev-list HEAD --count --first-parent)" "$(git rev-parse --short HEAD)")
  else
    printf "${_pkgver}~%s" "$(git rev-list HEAD --count --first-parent)"
  fi
}

Edit: As in someone already tagged a 6.0.0 version. Maybe that tag shouldn’t be there?

Hmmm, that may be from the original plan to call it 6.0 before we settled on 5.99. Unfortunately tags do not sync automatically in git between local repos and somebody may have force pushed all tags <.<

Can the tag be removed? It’s undermining the whole reason for version tags imho. My PKGBUILD uses the newer GitLab repository.

Ah, right, I forgot. I disabled compressing the package, so I don’t have to wait for my machine to first compress the package, and then decompress it again then I install it. I routinely delete my build directories afterwards anyway, so the bigger file size if no problem for me. Until now that is, when I offer to transfer the file to somebody else.

In my /etc/makepkg.conf I’ve enabled this line:
PKGEXT=’.pkg.tar’

Thanks @StefanHamminga and @cedric – Stefan’s build works fine here. Building the AUR version just for fun. I was confused initially looking at the AUR package seeing the last update was quite some time ago, but released it builds the latest kicad git version, so it is just the build that has not been updated in awhile.

With AUR packages, is there any way to have both the released and AUR version installed?

I pulled up the design – looks like a 4-layer design. I’d guess quite a bit work went into this design.

There appears to be some length matching and diff pair routing. Are there new features in the nightly build that would help with this?

The new design rules system would help with this, but the Pi folks didn’t use it for this design

I’ve asked the same question on the RPi forum but none of the designers had replied. Since 5.1 branch, heck even v4 is perfectly capable to design differential pairs, I still don’t get why they had used nightly builds for this task.

Working today on the CM4IO board and still yet to see a reason.

Any ideas?