2 changes are in queue on my workstation, one is u-boot 2018.11, the other is updating the Dev patchset and beginning to iron out 4.19 Kernel. The first I honestly don't see any issues with moving forward, but want people to know about it, the second is a bit of a hairball and I'll need some help with debugging, and in fixing.
Detail of changes:
U-boot: Currently Meson64 and Odroid C2 are using 2018.05 and 2018.07, respectively. I will be moving all to 2018.11, and eliminating the "specialness" of the Odroid C2 in our build system, so Meson64 will be inheriting the C2 boot script under the "Meson64 name, it will no longer have its own u-boot patch folder/etc. The board will finally be fully integrated into the Meson64 configuration, although it will still have the special Odroid firmware blob (all Amlogic SoC's have their own blobs, so no special changes need made to allow for the C2 to have a different one than the K2)
Current Concerns:
packaging scripts on 4.14 kernel are not creating a symlinked named "Image" for the updated boot script. I didn't consider that and only caught it today. U-boot is obviously unimpressed.
Kernel 4.19: This will eventually become the "Default" kernel, once it has been debugged and proven out, as Amlogic Mainline kernels can now be easily patched with full video decoder support (already done), and Mali support is available (I need to finish integrating that, later date)
Current concerns:
-HDMI displays seem to be a sore spot, I have 1 that works flawlessly (hilariously a 7" waveshare-like HDMI), while the other needs to be plugged in after boot to work, and an HDMI-DVI adapter one is nonfunctional. (it seems to think it's attached, but no image)
- I am getting a million "failed to change cpu frequency: -5" errors again. The clock marked as critical fix is in there, needs verified as it looks different than the old one.
- I had to disable CEC entirely to get the system to boot with a display attached, it would fault, reboot, fault, etc. Plugging in a display after boot yielded an oops. No CEC = that problem is gone.
Tagging @Neil Armstrong, for tracking if interested/have ideas. I'm using Neil's always helpful meta-meson patchset, these were squirreled away in "next" so I assume they are not complete/some WIP, so this can be some good feedback/etc. No one can break things like an end user.
Question
TonyMac32
2 changes are in queue on my workstation, one is u-boot 2018.11, the other is updating the Dev patchset and beginning to iron out 4.19 Kernel. The first I honestly don't see any issues with moving forward, but want people to know about it, the second is a bit of a hairball and I'll need some help with debugging, and in fixing.
Detail of changes:
U-boot: Currently Meson64 and Odroid C2 are using 2018.05 and 2018.07, respectively. I will be moving all to 2018.11, and eliminating the "specialness" of the Odroid C2 in our build system, so Meson64 will be inheriting the C2 boot script under the "Meson64 name, it will no longer have its own u-boot patch folder/etc. The board will finally be fully integrated into the Meson64 configuration, although it will still have the special Odroid firmware blob (all Amlogic SoC's have their own blobs, so no special changes need made to allow for the C2 to have a different one than the K2)
Current Concerns:
packaging scripts on 4.14 kernel are not creating a symlinked named "Image" for the updated boot script. I didn't consider that and only caught it today. U-boot is obviously unimpressed.
Kernel 4.19: This will eventually become the "Default" kernel, once it has been debugged and proven out, as Amlogic Mainline kernels can now be easily patched with full video decoder support (already done), and Mali support is available (I need to finish integrating that, later date)
Current concerns:
-HDMI displays seem to be a sore spot, I have 1 that works flawlessly (hilariously a 7" waveshare-like HDMI), while the other needs to be plugged in after boot to work, and an HDMI-DVI adapter one is nonfunctional. (it seems to think it's attached, but no image)
- I am getting a million "failed to change cpu frequency: -5" errors again. The clock marked as critical fix is in there, needs verified as it looks different than the old one.
- I had to disable CEC entirely to get the system to boot with a display attached, it would fault, reboot, fault, etc. Plugging in a display after boot yielded an oops. No CEC = that problem is gone.
Tagging @Neil Armstrong, for tracking if interested/have ideas. I'm using Neil's always helpful meta-meson patchset, these were squirreled away in "next" so I assume they are not complete/some WIP, so this can be some good feedback/etc. No one can break things like an end user.
Link to comment
Share on other sites
100 answers to this question
Recommended Posts