Sumo32 upgrade to linux 4.18 and U-Boot 2018.09 - Githubissues

edison-fw / meta-intel-edison

Here is the meta-intel-edison that builds, tries to stay up to date. Master is based on Yocto Poky Gatesgarth LTS 5.10.yy vanilla kernels. It builds a 32bit kernel (Gatesgarth branch 64bit) with ACPI enabled and corresponding rootfs. Telegram group: https://t.me/IntelEdison Web-site:

https://edison-fw.github.io/meta-intel-edison/

MIT License

60 stars 37 forks source link

Sumo32 upgrade to linux 4.18 and U-Boot 2018.09 #46

Closed htot closed 5 years ago

htot commented 5 years ago

This brings some interesting advances:

The i2c-6 on the non-acpi kernel has now been verified to work.
The acpi enabled U-Boot enables i2c-6 for the acpi kernel. Verified to work as well.
The non-acpi kernel now boots when U-Boot provides acpi tables (does not hang). Of course it lacks the acpi tables needed for the Edison Arduino, so doesn't work very well.
While debugging acpi tables it appears to be inconvenient that they get automatically loaded by the initramfs, as to update them you need to build kernel + initramfs-kernel and install. Just building tables as cpio (as intended by Mika / Andy) and loading by U-Boot, or building and installing as .deb and loading through configfs (me) is much quicker. This requires to introduce a command line option to disable loading the tables from the initramfs.
Unloading acpi-tables at run time still doesn't work and causes a kernel crash as before (NULL pointer reference).

alext-mkrs commented 5 years ago

Generally looks ok, but the last commit needs checking, such merge commits pollute the history, plus it seems to duplicate some other changes (I took only a cursory glance at that one though - my internet access is intermittent at the moment)

htot commented 5 years ago

I'll remove that last one then. I was experimenting to see if it makes sense to group commits with a merge commit so it is more clear they belong together. I can wait a bit for you to build and test?

htot commented 5 years ago

Removed the merge commit and upgraded u-boot to the freshly released 2018.09

alext-mkrs commented 5 years ago

Thanks! Those merge commits clump stuff together, so they're really just a history pollution, haven't seen anyone using them - mostly the opposite, everyone prohibits them.

My internet and build machine access is going to be on-and-off for about a week or so, not sure if you'd want to wait that long, as realistically I'll be able to test only some time next week and most probably closer to the end of it. I think you can merge if it works for you and we can sort out problems later if needed.

htot commented 5 years ago

Thanks! Those merge commits clump stuff together, so they're really just a history pollution, haven't seen anyone using them - mostly the opposite, everyone prohibits them.

I saw the linux kernel doing that and wondered if there was an advantage to that, like making sure that each commit results in a working build. But I agree, on GH it messes up the review process.

My internet and build machine access is going to be on-and-off for about a week or so, not sure if you'd want to wait that long, as realistically I'll be able to test only some time next week and most probably closer to the end of it. I think you can merge if it works for you and we can sort out problems later if needed.

Alright. I suspect I messed up .gitignore, don't know in which commit yet. So I will fix that first and then pull.

htot commented 5 years ago

And let the sorting out begin :-)