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"..
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?
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:
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:
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.
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.