Latest Image - Summer 2020 Release - RC2 (GSOC stuff)

Hi Everyone,

So RC2 is now out, all the "wl18xx" based devices now have working
Bluetooth again, config: CONFIG_SERIAL_SC16IS7XX completely broke it..

I'm planning to do the "full" burn in testing this Saturday, my targets are:

Windows 10 (2004)
Debian
Mac OS (Mojave, Catalina)

Here is what i did last 'time' which took about a full day of none stop testing:

https://github.com/beagleboard/Latest-Images/issues/26

Please reply with more things to verify..

Now GSOC students, please reply with still un-merged patches and what
kernel they are targeting. I'd like to get all these projects built
and merged by this Thursday, then we can do a final "RC" next week,
that may turn into "FInal"..

Regards,

Forgot to add, in all the "Buster" v4.19.x images, u-boot overlays is
enabled out of the box:

debug: [uname_r=4.19.94-ti-r50] ...
loading /boot/vmlinuz-4.19.94-ti-r50 ...
10162688 bytes read in 440 ms (22 MiB/s)
loading /boot/dtbs/4.19.94-ti-r50/am5729-beagleboneai.dtb ...
250582 bytes read in 16 ms (14.9 MiB/s)
uboot_overlays: [fdt_buffer=0x60000] ...
uboot_overlays: loading
/boot/dtbs/4.19.94-ti-r50/overlays/BBORG_FAN-A000.dtbo ...
519 bytes read in 5 ms (100.6 KiB/s)
loading /boot/initrd.img-4.19.94-ti-r50 ...
6618904 bytes read in 287 ms (22 MiB/s)

So the BBAI with FAN cape will run at full frequency. :wink:

and here is the image links:

https://elinux.org/Beagleboard:Latest-images-testing#Latest_Images_Testing

Regards,

Would anyone else like a u-boot patch for PocketBeagle such that EEPROMs at address 0x57 on either I2C1 or I2C2 would have cape identifiers such that GamePup, TechLab, and Grove PocketBeagle Capes would automatically load overlays?

Hi Robert,

The wiki page at https://elinux.org/Beagleboard:Latest-images-testing has some outdated info on the Sumer 2020 Release.
While the RC2 is marked (properly) has released in August 26, it says the final version was released in August 3rd!

Best regards,
José Gonçalves

A quarta-feira, 26 de agosto de 2020 à(s) 15:45:24 UTC+1, RobertCNelson escreveu:

Hi Robert,

Is there an updated schedule for the next stable image release?
I assume there are some blocking issues that prevented the Summer release to took place, inittialy postponed to Fall, acording to the Latest-image-testing wiki.
May we know what issues are preventing a new stable release?

Best regards,
José Gonçalves

A quarta-feira, 2 de setembro de 2020 à(s) 18:21:04 UTC+1, jose...@gmail.com escreveu:

Blocking items I know about:

  • BeagleBone AI rev A2 SuperSpeed USB verification - haven’t debugged why it may be slower
  • PocketBeagle cape overlay support

I think we need to address items at https://github.com/beagleboard/Latest-Images/milestone/2 and then a release can finally be made.

Fortunately or unfortunately, there has been a lot of development and it is taking some time for things to settle.

Hello Robert,

I would like to merge simpPRU and simpPRU into the images.
I am targeting kernel version: >= 4.19.

I build it using these docker images: https://hub.docker.com/repository/docker/simppru/amd64-build-image and https://hub.docker.com/repository/docker/simppru/arm32-build-image.
You can find pre-built releases here: https://github.com/VedantParanjape/simpPRU/releases

Link to the repository, the readme describes how to build from source: https://github.com/VedantParanjape/simpPRU

Currently these package have no dependency in the debian file, but they do require a working gcc-pru installation, I haven’t yet added the dependency as I have built packages for amd64 as-well as armhf, and gcc-pru doesn’t have a package distributed for amd64. So, if it is possible to release gcc-pru for amd64, it would be great, If yes, I will quickly update the debian files to add gcc-pru as it’s dependency, just let me know.

Regards,
Vedant Paranjape

Hello Mr RobertCNelson

I have a pull request 247

It is still open. Can you please look into it. To test it you can use the link provided in the commit message. I have rebased it so you probably will not have any problems merging it. I am targeting kernel 4.19. However jason has asked me to add additional feature for automatic loading of PRU firmware with this driver. Right now you need to install PRU firmware manually (here is a README) and then my driver’s probe function is called whenever the PRU firmware creates a rpmsg channel with the same .name attribute as in my driver. After this you will see a new gpiochip in /dev and /sys/class/gpio. So i am still trying to figure out how much of effort it would need to change this mechanism to automate firmware loading and if i would be able to finish it today since you will be merging today.