This question is probably mostly aimed at aTc:
Right now, you only provide precompiled U-Boot binaries in the OS. Nowhere on gitlab have I found where the sources for those are.
I know we've got at least one developer experienced with U-Boot now at this mailing list.
Could you please point us to the sources of the U-Boot we use?
I also think we should put the Pyra-U-Boot sources to our gitlab so we can start adding Pyra-Specific stuff (bootlogo, mini charger, menu, etc.) to it.
What does everyone else think?
Hi,
Am 14.06.2018 um 04:32 schrieb Michael Mrozek EvilDragon@openpandora.org:
This question is probably mostly aimed at aTc:
Right now, you only provide precompiled U-Boot binaries in the OS. Nowhere on gitlab have I found where the sources for those are.
I know we've got at least one developer experienced with U-Boot now at this mailing list.
Could you please point us to the sources of the U-Boot we use?
I also think we should put the Pyra-U-Boot sources to our gitlab so we can start adding Pyra-Specific stuff (bootlogo, mini charger, menu, etc.) to it.
Well, you can't add this to U-Boot. U-Boot can't drive a MIPI display (unless you back-port a lot of thing from kernel to u-boot).
So this should all go to the inird where you can load the panel driver kernel module.
The task of U-Boot is to get the inird up and running as fast as possible.
This means that there should be a project (incl. git repo) to build such an initrd.
BR, Nikolaus
Am Donnerstag, den 14.06.2018, 12:55 +0200 schrieb H. Nikolaus Schaller:
Hi,
I also think we should put the Pyra-U-Boot sources to our gitlab so we can start adding Pyra-Specific stuff (bootlogo, mini charger, menu, etc.) to it.
Well, you can't add this to U-Boot. U-Boot can't drive a MIPI display (unless you back-port a lot of thing from kernel to u-boot).
Yes, and that's exactly what we did with the Pandora, for example. Initialize the display - otherwise, you can't show a boot menu where you can choose to boot from multiple sources.
So this should all go to the inird where you can load the panel driver kernel module.
That's too late for a boot menu, as then the kernel has already been loaded.
Unless it's possible to choose a kernel and boot partition AFTER initrd.
Am 14.06.2018 um 13:04 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Donnerstag, den 14.06.2018, 12:55 +0200 schrieb H. Nikolaus Schaller:
Hi,
I also think we should put the Pyra-U-Boot sources to our gitlab so we can start adding Pyra-Specific stuff (bootlogo, mini charger, menu, etc.) to it.
Well, you can't add this to U-Boot. U-Boot can't drive a MIPI display (unless you back-port a lot of thing from kernel to u-boot).
Yes, and that's exactly what we did with the Pandora, for example. Initialize the display - otherwise, you can't show a boot menu where you can choose to boot from multiple sources.
You can, do that in the initrd/initramfs and can even write shell script code for that.
Much easier to maintain. And you can boot from SD, USB, Network, WLAN or whatever the kernel supports.
So it simply adds another stage of booting
BootROM -> MLO -> U-Boot -> Kernel from partitions U-Boot can search BootROM -> MLO -> U-Boot -> Kernel with initramfs -> final Kernel from whichever partition
So this should all go to the inird where you can load the panel driver kernel module.
That's too late for a boot menu, as then the kernel has already been loaded.
No. The kernel from initramfs can load another kernel through kexec.
Unless it's possible to choose a kernel and boot partition AFTER initrd.
Yes, that is basically the only reason why anyone needs an initramfs. Besides speed for headless embedded systems.
BR, Nikolaus
On 14/06/18 12:16, H. Nikolaus Schaller wrote:
BootROM -> MLO -> U-Boot -> Kernel with initramfs -> final Kernel from whichever partition
Can I suggest that we have a tiny stripped down kernel (that doesn't change often - if at all) as the kernel that U-Boot kicks off, and in the initramfs we look for a particular key held down (say the pyra key) and drop into the initrd ram disk using busybox as init (only if the key is held down - could possibly be a boot menu for SD / USB ?), the idea being that this can be used as an emergency rescue environment that is even independent of the main OS on the internal flash.
I've hacked around with the likes of extlinux a kernel and busybox in VM a fair bit and wouldn't mind having a bash at this when I can, but it bares a general discussion so it behaves in the way everyone wants and expects!
Chris
Am Donnerstag, den 14.06.2018, 12:34 +0100 schrieb Mr C Camacho:
I'd also suggest using a minimal kernel here, as it would reduce boottime dramatically.
The minimum kernel could also show the current battery charge (on screen or via the lid LEDs) when you're charging in a more advanced state.
It would have multiple uses then - boot menu, battery status information, recovery.
On 14/06/18 12:16, H. Nikolaus Schaller wrote:
BootROM -> MLO -> U-Boot -> Kernel with initramfs -> final Kernel from whichever partition
Can I suggest that we have a tiny stripped down kernel (that doesn't change often - if at all) as the kernel that U-Boot kicks off, and in the initramfs we look for a particular key held down (say the pyra key) and drop into the initrd ram disk using busybox as init (only if the key is held down - could possibly be a boot menu for SD / USB ?), the idea being that this can be used as an emergency rescue environment that is even independent of the main OS on the internal flash.
I've hacked around with the likes of extlinux a kernel and busybox in VM a fair bit and wouldn't mind having a bash at this when I can, but it bares a general discussion so it behaves in the way everyone wants and expects!
Chris
Am 14.06.2018 um 14:15 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Donnerstag, den 14.06.2018, 12:34 +0100 schrieb Mr C Camacho:
I'd also suggest using a minimal kernel here, as it would reduce boottime dramatically.
That is the target.
The minimum kernel could also show the current battery charge (on screen or via the lid LEDs) when you're charging in a more advanced state.
It would have multiple uses then - boot menu, battery status information, recovery.
Good idea and seems all to be possible if we: * have its separate defconfig to creates a minimal kernel (well 4.5MB -20% doesn't matter much). * include omapdss, mipi, panel, keyboard, led, fuel gauge, charger drivers * compiled into the kernel ("y" not "m") * and a minimal root file system to collect partitions and battery state and print on an text console screen * and wait for the user to request something (boot, install, recovery shell, power down, ...) * rootfs compiled into the kernel as initramfs
I had started such code long time ago for the Letux 400 netbook:
1. shell script showing and managing a boot menu:
http://git.goldelico.com/?p=l400-rootfs.git;a=blob;f=config/root/recover;h=3...
2. script to build a 3MB bootable Debian rootfs which includes the boot menu script:
http://git.goldelico.com/?p=l400-rootfs.git;a=blob_plain;f=config/root/mkmin...
I don't know if Stretch can be stripped down the same way (this was Debian Etch or Squeeze if I remember correctly).
So someone can pick this up. Probably more the idea behind than this code.
BR, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [180614 12:36]:
I had started such code long time ago for the Letux 400 netbook:
shell script showing and managing a boot menu:
http://git.goldelico.com/?p=l400-rootfs.git;a=blob;f=config/root/recover;h=3...
For a basic boot menu with framebuffer console maybe take a look at kexecboot. For droid4 we have a 4MB buildroot based bootloader image with kexecboot containing wpa_supplicant, iw, mkfs.ext4, and dropbear.
Regards,
Tony
On 06/14/2018 04:32 AM, Michael Mrozek wrote:
This question is probably mostly aimed at aTc:
Right now, you only provide precompiled U-Boot binaries in the OS. Nowhere on gitlab have I found where the sources for those are.
I think the current one is based on the one here https://dev.pyra-handheld.com/notaz/pyra-u-boot
Im not entirely sure, because, as with the kernel, there have been quite a few different versions of the pyra uboot. I wanted to have a bootmenu, and an easy way to have the os configure boot options for multiple kernels, so i had a version of the letux uboot with extlinux enabled, zmatt did some fixes , and then notaz took all of the stuff and added a few more things, and it ended up on there. Not much has happened to it since then. It's probably horribly out of date with the letux uboot now.
Hi there,
I am Patrick one of the new guys. I don't have much to show off right now, but I thought it might be a good idea to tell you what I want to do within the next days.
Today, I took the u-boot branch "letux-2016.11" from git://git.goldelico.com/gta04-uboot.git
and started to rebased it on top of v2018.05 of mainline git://git.denx.de/u-boot.git
I was able to complete all merges, but v2018.05 is still not able to compile letux_lc15_4gb_evm_defconfig. I expect it will take some time to convert all the legacy CONFIG options to Kconfig.
Call me crazy, but I strongly believe in mainline. And in my opinion it is the only possibility to keep our software maintainable.
If I succeed and build a current u-boot for the pyra. My next step would be to split pyra support into small pieces and send them step by step to mainline. I know that is a hard way, but trust me it is worth it. Especially for a device like the Pyra, which should live for years and is not obsolete within a few month.
Currently all my work is just local, but as soon as something is working or someone else shows interest in my work I can push it to: https://dev.pyra-handheld.com git://git.goldelico.com/gta04-uboot.git or github
Nice dreams, Patrick
p.s.: Same timezone as ED but I need more sleep than him.
On 14.06.2018 23:55, aTc wrote:
On 06/14/2018 04:32 AM, Michael Mrozek wrote:
This question is probably mostly aimed at aTc:
Right now, you only provide precompiled U-Boot binaries in the OS. Nowhere on gitlab have I found where the sources for those are.
I think the current one is based on the one here https://dev.pyra-handheld.com/notaz/pyra-u-boot
Im not entirely sure, because, as with the kernel, there have been quite a few different versions of the pyra uboot. I wanted to have a bootmenu, and an easy way to have the os configure boot options for multiple kernels, so i had a version of the letux uboot with extlinux enabled, zmatt did some fixes , and then notaz took all of the stuff and added a few more things, and it ended up on there. Not much has happened to it since then. It's probably horribly out of date with the letux uboot now.
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On Fr, 2018-06-15 at 00:36 +0200, patrick wrote:
Yes, we definitely should stay mainline wherever possible!
About the GIT and U-Boot: Well, that's up to Nikolaus. If he also would be interested in using the latest U-Boot version for Letux, then it makes sense using his GIT.
Otherwise, please set up a U-Boot git on our server and we'll use that one.
Hi there,
I am Patrick one of the new guys. I don't have much to show off right now, but I thought it might be a good idea to tell you what I want to do within the next days.
Today, I took the u-boot branch "letux-2016.11" from git://git.goldelico.com/gta04-uboot.git
and started to rebased it on top of v2018.05 of mainline git://git.denx.de/u-boot.git
I was able to complete all merges, but v2018.05 is still not able to compile letux_lc15_4gb_evm_defconfig. I expect it will take some time to convert all the legacy CONFIG options to Kconfig.
Call me crazy, but I strongly believe in mainline. And in my opinion it is the only possibility to keep our software maintainable.
If I succeed and build a current u-boot for the pyra. My next step would be to split pyra support into small pieces and send them step by step to mainline. I know that is a hard way, but trust me it is worth it. Especially for a device like the Pyra, which should live for years and is not obsolete within a few month.
Currently all my work is just local, but as soon as something is working or someone else shows interest in my work I can push it to: https://dev.pyra-handheld.com git://git.goldelico.com/gta04-uboot.git or github
Nice dreams, Patrick
p.s.: Same timezone as ED but I need more sleep than him.
On 14.06.2018 23:55, aTc wrote:
On 06/14/2018 04:32 AM, Michael Mrozek wrote:
This question is probably mostly aimed at aTc:
Right now, you only provide precompiled U-Boot binaries in the OS. Nowhere on gitlab have I found where the sources for those are.
I think the current one is based on the one here https://dev.pyra-handheld.com/notaz/pyra-u-boot
Im not entirely sure, because, as with the kernel, there have been quite a few different versions of the pyra uboot. I wanted to have a bootmenu, and an easy way to have the os configure boot options for multiple kernels, so i had a version of the letux uboot with extlinux enabled, zmatt did some fixes , and then notaz took all of the stuff and added a few more things, and it ended up on there. Not much has happened to it since then. It's probably horribly out of date with the letux uboot now.
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi,
Am 15.06.2018 um 00:36 schrieb patrick patrick@wylight.de:
Hi there,
I am Patrick one of the new guys. I don't have much to show off right now, but I thought it might be a good idea to tell you what I want to do within the next days.
Today, I took the u-boot branch "letux-2016.11" from git://git.goldelico.com/gta04-uboot.git
and started to rebased it on top of v2018.05 of mainline git://git.denx.de/u-boot.git
Nice!
I was able to complete all merges, but v2018.05 is still not able to compile letux_lc15_4gb_evm_defconfig. I expect it will take some time to convert all the legacy CONFIG options to Kconfig.
Yes, that is the key problem with these upgrades/rebases.
Call me crazy, but I strongly believe in mainline. And in my opinion it is the only possibility to keep our software maintainable.
I almost agree for normal software, but there is an exception: the bootloader.
The reason is that we have limited resources and therefore should to do the important things. Now, the bootloader is important, but does rebasing from e.g. 2016.11 to 2018.05 give us new features we need or are missing?
For me the boot-loader should be touched on only rarely and only if it is missing something (e.g. better 4GB support). And then be released after careful testing. If we would apply a rolling rebase model (like we do for the letux kernel) it binds a lot of time to do the tests... And not to forget how to rollout u-boot updates to users and support them if something went wrong.
In my experience with u-boot it takes approx. 5 years that there is something significantly new so that investing some months of upgrading, fixing bugs and polishing is warranted.
Last time we did this with letux-os was 2016. There we got the problem that our 2013 u-boot was not able to be extended to handle OneNAND (for a different device than the Pyra). And it did not support OMAP5...
So this was a good point in time rebase and fix and extend the code. But then we did leave it as is. Especially because the config system was in the middle of being upgraded and there were experiments with device tree in u-boot. So we decides to "never touch a running system".
But Ido not want to say that your efforts are of no use. They are useful to learn how to do this upgrade and prepare for a moment when we need it.
If I succeed and build a current u-boot for the pyra. My next step would be to split pyra support into small pieces and send them step by step to mainline.
Yes, that is a good idea. The more is in mainline the less patches we need...
I know that is a hard way, but trust me it is worth it. Especially for a device like the Pyra, which should live for years and is not obsolete within a few month.
Well, u-boot 2016.11 (or any other version) isn't as well.
Currently all my work is just local, but as soon as something is working or someone else shows interest in my work I can push it to: https://dev.pyra-handheld.com git://git.goldelico.com/gta04-uboot.git
if you need write access at some point, please contact me.
or github
git://git.goldelico.com/gta04-uboot.git is mirrored to https://github.com/goldelico/gta04-uboot
Nice dreams, Patrick
p.s.: Same timezone as ED but I need more sleep than him.
I do as well :)
On 14.06.2018 23:55, aTc wrote:
On 06/14/2018 04:32 AM, Michael Mrozek wrote:
This question is probably mostly aimed at aTc:
Right now, you only provide precompiled U-Boot binaries in the OS. Nowhere on gitlab have I found where the sources for those are.
I think the current one is based on the one here https://dev.pyra-handheld.com/notaz/pyra-u-boot
Im not entirely sure, because, as with the kernel, there have been quite a few different versions of the pyra uboot. I wanted to have a bootmenu, and an easy way to have the os configure boot options for multiple kernels, so i had a version of the letux uboot with extlinux enabled, zmatt did some fixes , and then notaz took all of the stuff and added a few more things, and it ended up on there. Not much has happened to it since then. It's probably horribly out of date with the letux uboot now.
I have checked and it was branched off after 31 jul 2017. Since then there are just 10 patches in letux-u-boot. Only the last two are Pyra related (Tony's 4GB patches).
pyra-u-boot got 13 patches on top of the branch point. I have looked a little into them and some are obviously good for inclusion. Some may need a little discussion (e.g. noop-patches like "support palmas").
So as soon as I find time, I will go through them.
BR, Nikolaus
On 15.06.2018 17:42, H. Nikolaus Schaller wrote:
Am 15.06.2018 um 00:36 schrieb patrick patrick@wylight.de:
...
I was able to complete all merges, but v2018.05 is still not able to compile letux_lc15_4gb_evm_defconfig. I expect it will take some time to convert all the legacy CONFIG options to Kconfig.
Yes, that is the key problem with these upgrades/rebases.
Call me crazy, but I strongly believe in mainline. And in my opinion it is the only possibility to keep our software maintainable.
I almost agree for normal software, but there is an exception: the bootloader.
The reason is that we have limited resources and therefore should to do the important things. Now, the bootloader is important, but does rebasing from e.g. 2016.11 to 2018.05 give us new features we need or are missing?
For me the boot-loader should be touched on only rarely and only if it is missing something (e.g. better 4GB support). And then be released after careful testing. If we would apply a rolling rebase model (like we do for the letux kernel) it binds a lot of time to do the tests... And not to forget how to rollout u-boot updates to users and support them if something went wrong.
In my experience with u-boot it takes approx. 5 years that there is something significantly new so that investing some months of upgrading, fixing bugs and polishing is warranted.
Last time we did this with letux-os was 2016. There we got the problem that our 2013 u-boot was not able to be extended to handle OneNAND (for a different device than the Pyra). And it did not support OMAP5...
So this was a good point in time rebase and fix and extend the code. But then we did leave it as is. Especially because the config system was in the middle of being upgraded and there were experiments with device tree in u-boot. So we decides to "never touch a running system". That's an interesting topic to discus, because my opinion is quite the
opposite. But I don't want to start an argument on my second day on this list so let's keep that discussion for the release party and in the mean time I try to persuade by action.
But Ido not want to say that your efforts are of no use. They are useful to learn how to do this upgrade and prepare for a moment when we need it.
If I succeed and build a current u-boot for the pyra. My next step would be to split pyra support into small pieces and send them step by step to mainline.
Yes, that is a good idea. The more is in mainline the less patches we need...
I know that is a hard way, but trust me it is worth it. Especially for a device like the Pyra, which should live for years and is not obsolete within a few month.
Well, u-boot 2016.11 (or any other version) isn't as well.
Currently all my work is just local, but as soon as something is working or someone else shows interest in my work I can push it to: https://dev.pyra-handheld.com git://git.goldelico.com/gta04-uboot.git
if you need write access at some point, please contact me.
or github
git://git.goldelico.com/gta04-uboot.git is mirrored to https://github.com/goldelico/gta04-uboot
I have a compiling tree, now. I am pretty sure it won't boot, but at least the compiler is happy.
I tried to login/register on https://dev.pyra-handheld.com but didn't got a mail till, now.
So I forked your repo on github and pushed a new branch with my rebase: https://github.com/bruenn/gta04-uboot/tree/v2018.05-pyra-v1
Regards, Patrick
Nice dreams, Patrick
p.s.: Same timezone as ED but I need more sleep than him.
I do as well :)
On 14.06.2018 23:55, aTc wrote:
On 06/14/2018 04:32 AM, Michael Mrozek wrote:
This question is probably mostly aimed at aTc:
Right now, you only provide precompiled U-Boot binaries in the OS. Nowhere on gitlab have I found where the sources for those are.
I think the current one is based on the one here https://dev.pyra-handheld.com/notaz/pyra-u-boot
Im not entirely sure, because, as with the kernel, there have been quite a few different versions of the pyra uboot. I wanted to have a bootmenu, and an easy way to have the os configure boot options for multiple kernels, so i had a version of the letux uboot with extlinux enabled, zmatt did some fixes , and then notaz took all of the stuff and added a few more things, and it ended up on there. Not much has happened to it since then. It's probably horribly out of date with the letux uboot now.
I have checked and it was branched off after 31 jul 2017. Since then there are just 10 patches in letux-u-boot. Only the last two are Pyra related (Tony's 4GB patches).
pyra-u-boot got 13 patches on top of the branch point. I have looked a little into them and some are obviously good for inclusion. Some may need a little discussion (e.g. noop-patches like "support palmas").
So as soon as I find time, I will go through them.
BR, Nikolaus
Hi Patrick,
Am 16.06.2018 um 01:18 schrieb patrick patrick@wylight.de:
On 15.06.2018 17:42, H. Nikolaus Schaller wrote:
Am 15.06.2018 um 00:36 schrieb patrick patrick@wylight.de:
So this was a good point in time rebase and fix and extend the code. But then we did leave it as is. Especially because the config system was in the middle of being upgraded and there were experiments with device tree in u-boot. So we decided to "never touch a running system".
That's an interesting topic to discus, because my opinion is quite the
opposite. But I don't want to start an argument on my second day on this list so let's keep that discussion for the release party and in the mean time I try to persuade by action.
Yes, let's do it!
My argument is not a technical one but an organizational one... Or weighting usefulness vs. efforts.
And there I see that rebasing u-boot to every new release from upstream doesn't add many significant features, but takes a lot of testing time.
Therefore, if we wait until a big set of new features have accumulated and then do the rebase and testing once, it is a much better improvement for the invested time.
For the kernel I see the reverse situation. Every new release brings significant improvements - either from upstream or by our own work to fill gaps (e.g. missing device drivers). For U-Boot we have almost no missing features because it does what it is designed for.
Therefore for the kernel, the rolling rebase scheme has turned out to be better manageable than taking a snapshot, develop and fix missing things the next years. But not be able to rebase it to a newer kernel because kernel APIs have diverged too much.
Any my final though is that u-boot belongs to the basis we want to build something on. So it should be stabilized - but not changed too often...
Where I see the next good situation for upgrading u-boot source code is when there is no longer a (horrible) mixture of old u-boot config and Kconfig where it sometimes needs experimentation to find out what should be configured where. I don't know how the status of 2018.05 is but 2017 u-boot wasn't much better than 2016.
if you need write access at some point, please contact me.
or github
git://git.goldelico.com/gta04-uboot.git is mirrored to https://github.com/goldelico/gta04-uboot
I have a compiling tree, now. I am pretty sure it won't boot, but at least the compiler is happy.
I tried to login/register on https://dev.pyra-handheld.com but didn't got a mail till, now.
So I forked your repo on github and pushed a new branch with my rebase: https://github.com/bruenn/gta04-uboot/tree/v2018.05-pyra-v1
Nice. If I find time, I'll take a look into it.
Maybe we should pull it into http://git.goldelico.com/?p=gta04-uboot.git;a=heads so that it shows up as
letux-2018.05
or alternatively as
work/patrick/letux-2018.05
and give you write access so that you can simply push.
For getting access, please register to http://projects.goldelico.com/p/gta04-uboot/ provide your public key in the user's settings and I can add you to the "Happy Crew" which gives you write access to the git repo.
BR and thanks, Nikolaus
On 16.06.2018 13:28, H. Nikolaus Schaller wrote:
Hi Patrick,
Am 16.06.2018 um 01:18 schrieb patrick patrick@wylight.de:
On 15.06.2018 17:42, H. Nikolaus Schaller wrote:
Am 15.06.2018 um 00:36 schrieb patrick patrick@wylight.de:
So this was a good point in time rebase and fix and extend the code. But then we did leave it as is. Especially because the config system was in the middle of being upgraded and there were experiments with device tree in u-boot. So we decided to "never touch a running system".
That's an interesting topic to discus, because my opinion is quite the
opposite. But I don't want to start an argument on my second day on this list so let's keep that discussion for the release party and in the mean time I try to persuade by action.
Yes, let's do it!
My argument is not a technical one but an organizational one... Or weighting usefulness vs. efforts.
And there I see that rebasing u-boot to every new release from upstream doesn't add many significant features, but takes a lot of testing time. Maybe I am a bit naive here but besides from booting, what do you have
to test? In the end the only u-boot feature you are using is one straight boot path.
Therefore, if we wait until a big set of new features have accumulated and then do the rebase and testing once, it is a much better improvement for the invested time.
In my personal experience I made a big mistake, waiting to long to rebase so that rebasing costs me a lot of time. Since all my code is mainline. All I do is compile and boot test once in a while. I don't have to ship new versions, but I know that if I had to I could immediately start without rebasing multiple iterations of u-boot first. Working on the latest version, has the same benefits as for the kernel: - you have community support - you can send your changes immediately to mainline While getting them accepted can sometimes be a real pain, it is worth it in the end. You get code review for free! And in my experience we reduced my initial code to 30%. Since my board is in mainline it received 7 commits. Only two of them are from me. The rest was bug-fixes and global cleanups made by the community. All for free!
For the kernel I see the reverse situation. Every new release brings significant improvements - either from upstream or by our own work to fill gaps (e.g. missing device drivers). For U-Boot we have almost no missing features because it does what it is designed for.
Therefore for the kernel, the rolling rebase scheme has turned out to be better manageable than taking a snapshot, develop and fix missing things the next years. But not be able to rebase it to a newer kernel because kernel APIs have diverged too much.
Any my final though is that u-boot belongs to the basis we want to build something on. So it should be stabilized - but not changed too often...
In my opinion every software is the same. They all have bugs. So all of them need to be update able. If I update software, I have to make sure the update isn't making anything worse. So I have to test. If I master my testcases I don't have to care about frequent updates anymore. If my test process is good, I don't have to make a distinction between small bugfix updates or big version upgrades. They are both best tested and fulfill the same quality standards.
Where I see the next good situation for upgrading u-boot source code is when there is no longer a (horrible) mixture of old u-boot config and Kconfig where it sometimes needs experimentation to find out what should be configured where. I don't know how the status of 2018.05 is but 2017 u-boot wasn't much better than 2016.
While getting into mainline, they will tell you exactly what config option you have to move to Kconfig, now. If you have your board in mainline the community will convert the rest of config files to Kconfig for you!
if you need write access at some point, please contact me.
or github
git://git.goldelico.com/gta04-uboot.git is mirrored to https://github.com/goldelico/gta04-uboot
I have a compiling tree, now. I am pretty sure it won't boot, but at least the compiler is happy.
I tried to login/register on https://dev.pyra-handheld.com but didn't got a mail till, now.
So I forked your repo on github and pushed a new branch with my rebase: https://github.com/bruenn/gta04-uboot/tree/v2018.05-pyra-v1
Nice. If I find time, I'll take a look into it.
Maybe we should pull it into http://git.goldelico.com/?p=gta04-uboot.git;a=heads so that it shows up as
letux-2018.05
Well, if that quick & dirty rebase is working for your other boards, sure take it.
or alternatively as
work/patrick/letux-2018.05 I would prefer this. Because my target is to ultimately get rid of any
out tree patches for the Pyra. To reach there I will have to remove everything not Pyra related from my intermediate branch and then regroup the changes in small commits which I can send upstream one by one. On that way I will create a lot of new branches and rebases. You can get an idea from the names. <u-boot-base-version>-pyra-<rebase-version>: f.e.: v2018.05-pyra-v1 -> v2018.05-pyra-v2... v2018.07-rc1-pyra-v1.... Today I begun divide and conquer and removed beagle and gta files from v2018.05-pyra-v2. so my diff was shrinked from: 197 files changed, 13598 insertions(+), 74 deletions(-) to: 56 files changed, 2335 insertions(+), 74 deletions(-)
To continue I have some questions: Which is the correct boot-scr/dtb/defconfig for the Pyra? uEnv-letux-cortex15+pyra.txt uEnv-letux-cortex15.txt uEnv-letux-cortex8.txt uEnv-omap5-uevm+pyra.txt uEnv-omap5-uevm.txt
OSD3358 is not relevant for the Pyra is it?
What is board/goldelico/cmd_monitor.c? I didn't found any reference within the u-boot repository.
and give you write access so that you can simply push.
For getting access, please register to http://projects.goldelico.com/p/gta04-uboot/ provide your public key in the user's settings and I can add you to the "Happy Crew" which gives you write access to the git repo.
Done. Small note: the webinterface doesn't except my ed25519 key. Maybe it's just a config option or upgrade away. For now, I generated a rsa one.
BR and thanks, Nikolaus
Hi Patrick,
Am 18.06.2018 um 00:57 schrieb patrick patrick@wylight.de:
On 16.06.2018 13:28, H. Nikolaus Schaller wrote:
Hi Patrick,
Am 16.06.2018 um 01:18 schrieb patrick patrick@wylight.de:
On 15.06.2018 17:42, H. Nikolaus Schaller wrote:
Am 15.06.2018 um 00:36 schrieb patrick patrick@wylight.de:
So this was a good point in time rebase and fix and extend the code. But then we did leave it as is. Especially because the config system was in the middle of being upgraded and there were experiments with device tree in u-boot. So we decided to "never touch a running system".
That's an interesting topic to discus, because my opinion is quite the
opposite. But I don't want to start an argument on my second day on this list so let's keep that discussion for the release party and in the mean time I try to persuade by action.
Yes, let's do it!
My argument is not a technical one but an organizational one... Or weighting usefulness vs. efforts.
And there I see that rebasing u-boot to every new release from upstream doesn't add many significant features, but takes a lot of testing time. Maybe I am a bit naive here but besides from booting, what do you have
to test? In the end the only u-boot feature you are using is one straight boot path.
No. There are upstream changes that may break your system and your board may boot, but not everything has been initialized in the same way the kernel relies on. For example we have some special initialization for the charger chip.
And the key problem we have with kernel development is that kernel maintainers do not accept everything. So there is a zombie state where upstream does not care about private work, because they don't see it.
Therefore, if we wait until a big set of new features have accumulated and then do the rebase and testing once, it is a much better improvement for the invested time.
In my personal experience I made a big mistake, waiting to long to rebase so that rebasing costs me a lot of time.
Yes, it did cost us ca. 2 months to rebase 2013 to 2016.
Since all my code is mainline.
Ok, if you are happy to get to that point. We are hunting for this for years to get in the same state for the kernel but it is impossible.
All I do is compile and boot test once in a while. I don't have to ship new versions, but I know that if I had to I could immediately start without rebasing multiple iterations of u-boot first. Working on the latest version, has the same benefits as for the kernel:
- you have community support
- you can send your changes immediately to mainline
While getting them accepted can sometimes be a real pain, it is worth it in the end. You get code review for free! And in my experience we reduced my initial code to 30%. Since my board is in mainline it received 7 commits. Only two of them are from me. The rest was bug-fixes and global cleanups made by the community. All for free!
My key concern is that you don't get everything upstream. If you get it it is nice.
For the kernel I see the reverse situation. Every new release brings significant improvements - either from upstream or by our own work to fill gaps (e.g. missing device drivers). For U-Boot we have almost no missing features because it does what it is designed for.
Therefore for the kernel, the rolling rebase scheme has turned out to be better manageable than taking a snapshot, develop and fix missing things the next years. But not be able to rebase it to a newer kernel because kernel APIs have diverged too much.
Any my final though is that u-boot belongs to the basis we want to build something on. So it should be stabilized - but not changed too often...
In my opinion every software is the same. They all have bugs. So all of them need to be update able.
Well, this contradicts your idea of that there are no bugs if it passes the compile&boot test :)
If I update software, I have to make sure the update isn't making anything worse. So I have to test. If I master my testcases I don't have to care about frequent updates anymore. If my test process is good, I don't have to make a distinction between small bugfix updates or big version upgrades. They are both best tested and fulfill the same quality standards.
Yes, that is correct.
Where I see the next good situation for upgrading u-boot source code is when there is no longer a (horrible) mixture of old u-boot config and Kconfig where it sometimes needs experimentation to find out what should be configured where. I don't know how the status of 2018.05 is but 2017 u-boot wasn't much better than 2016.
While getting into mainline, they will tell you exactly what config option you have to move to Kconfig, now. If you have your board in mainline the community will convert the rest of config files to Kconfig for you!
Yes, that would be nice.
Anyways, if you think it is the best way and can do it I am fine with this. I just want to make sure that we are working on the most important things (from my overall view we have more than 10 times as many issues with kernel than with u-boot) and they do not end in a cul-de-sac.
if you need write access at some point, please contact me.
or github
git://git.goldelico.com/gta04-uboot.git is mirrored to https://github.com/goldelico/gta04-uboot
I have a compiling tree, now. I am pretty sure it won't boot, but at least the compiler is happy.
I tried to login/register on https://dev.pyra-handheld.com but didn't got a mail till, now.
So I forked your repo on github and pushed a new branch with my rebase: https://github.com/bruenn/gta04-uboot/tree/v2018.05-pyra-v1
Nice. If I find time, I'll take a look into it.
Maybe we should pull it into http://git.goldelico.com/?p=gta04-uboot.git;a=heads so that it shows up as
letux-2018.05
Well, if that quick & dirty rebase is working for your other boards, sure take it.
Well, I always wonder why there is some "my board" and "your boards" notion. Letux OS is "our boards" and Pyra is one of ours. Of course everyone has favourites and not everyone has the same set of boards to really work and do tests.
or alternatively as
work/patrick/letux-2018.05 I would prefer this. Because my target is to ultimately get rid of any
out tree patches for the Pyra. To reach there I will have to remove everything not Pyra related from my intermediate branch and then regroup the changes in small commits which I can send upstream one by one.
On that way I will create a lot of new branches and rebases.
That is how we do it for the letux kernel as well. There we have ca. 30 feature branches and merge them together for every release. Similar to linux-next.
These branches are cleaned up and tried to get upstream making them empty after a while.
Unfortunately some are not empty since 5 years...
You can get an idea from the names. <u-boot-base-version>-pyra-<rebase-version>: f.e.: v2018.05-pyra-v1 -> v2018.05-pyra-v2... v2018.07-rc1-pyra-v1.... Today I begun divide and conquer and removed beagle and gta files from v2018.05-pyra-v2. so my diff was shrinked from: 197 files changed, 13598 insertions(+), 74 deletions(-) to: 56 files changed, 2335 insertions(+), 74 deletions(-)
I wonder if it would be possible to do the same for the gta/beagle files while you are alredy working on this, so that the whole letux u-boot can finally be upstreamed? Letux OS is not a private project, but for the community.
To continue I have some questions: Which is the correct boot-scr/dtb/defconfig for the Pyra? uEnv-letux-cortex15+pyra.txt
this one.
uEnv-letux-cortex15.txt
Letux Cortex 15 is the CPU board (which is to be used for different projects as well and can even be booted stand-alone) and + pyra is for the combination with the Pyra mainboard.
The idea is to be able to replace the CPU board by another one as easyly as possible and not have to dig into the pyra components.
Therefore, please keep lc15 and pyra separated! Having just a single pyra board upstream but not lc15 makes this upgrade path more painful.
uEnv-letux-cortex8.txt
this is an am3358 board.
uEnv-omap5-uevm+pyra.txt uEnv-omap5-uevm.txt
this is the omap5evm and there was a prototype of the pyra mainboard connected to the omap5evm by cables.
OSD3358 is not relevant for the Pyra is it?
No, that is also the AM3358 chip (inside a module).
What is board/goldelico/cmd_monitor.c? I didn't found any reference within the u-boot repository.
That is a tool built into SPL which allows you to break into the serial boot process and have some very primitive console commands.
This is useful if a board can not access DRAM properly. But we don't need that regularity.
and give you write access so that you can simply push.
For getting access, please register to http://projects.goldelico.com/p/gta04-uboot/ provide your public key in the user's settings and I can add you to the "Happy Crew" which gives you write access to the git repo.
Done.
Ok, you are now member of the happy crew!
Small note: the webinterface doesn't except my ed25519 key. Maybe it's just a config option or upgrade away.
Seems to be too new for Indefero. Unfortunately, Indefero isn't maintained for a while.
For now, I generated a rsa one.
So please test. If it does not work, I have a debug procedure and we could always solve it.
BR and thans, Nikolaus
On 18.06.2018 07:17, H. Nikolaus Schaller wrote:
Hi Patrick,
Am 18.06.2018 um 00:57 schrieb patrick patrick@wylight.de:
On 16.06.2018 13:28, H. Nikolaus Schaller wrote:
Hi Patrick,
Am 16.06.2018 um 01:18 schrieb patrick patrick@wylight.de:
On 15.06.2018 17:42, H. Nikolaus Schaller wrote:
Am 15.06.2018 um 00:36 schrieb patrick patrick@wylight.de:
So this was a good point in time rebase and fix and extend the code. But then we did leave it as is. Especially because the config system was in the middle of being upgraded and there were experiments with device tree in u-boot. So we decided to "never touch a running system".
That's an interesting topic to discus, because my opinion is quite the
opposite. But I don't want to start an argument on my second day on this list so let's keep that discussion for the release party and in the mean time I try to persuade by action.
Yes, let's do it!
My argument is not a technical one but an organizational one... Or weighting usefulness vs. efforts.
And there I see that rebasing u-boot to every new release from upstream doesn't add many significant features, but takes a lot of testing time. Maybe I am a bit naive here but besides from booting, what do you have
to test? In the end the only u-boot feature you are using is one straight boot path.
No. There are upstream changes that may break your system and your board may boot, but not everything has been initialized in the same way the kernel relies on. For example we have some special initialization for the charger chip.
And the key problem we have with kernel development is that kernel maintainers do not accept everything. So there is a zombie state where upstream does not care about private work, because they don't see it.
I know, I have to maintain two out of tree kernel patches, too. The problem with these patches is, they are ugly hacks which could be done better. So until I find the time to clean them up correcty I have to rebase them regulary to keep them in sync with upstream.
Therefore, if we wait until a big set of new features have accumulated and then do the rebase and testing once, it is a much better improvement for the invested time.
In my personal experience I made a big mistake, waiting to long to rebase so that rebasing costs me a lot of time.
Yes, it did cost us ca. 2 months to rebase 2013 to 2016.
Since all my code is mainline.
Ok, if you are happy to get to that point. We are hunting for this for years to get in the same state for the kernel but it is impossible.
All I do is compile and boot test once in a while. I don't have to ship new versions, but I know that if I had to I could immediately start without rebasing multiple iterations of u-boot first. Working on the latest version, has the same benefits as for the kernel:
- you have community support
- you can send your changes immediately to mainline
While getting them accepted can sometimes be a real pain, it is worth it in the end. You get code review for free! And in my experience we reduced my initial code to 30%. Since my board is in mainline it received 7 commits. Only two of them are from me. The rest was bug-fixes and global cleanups made by the community. All for free!
My key concern is that you don't get everything upstream. If you get it it is nice.
Even if I don't get everything upstream I can reduce the number of out of tree patches and with it the effort to maintain them.
For the kernel I see the reverse situation. Every new release brings significant improvements - either from upstream or by our own work to fill gaps (e.g. missing device drivers). For U-Boot we have almost no missing features because it does what it is designed for.
Therefore for the kernel, the rolling rebase scheme has turned out to be better manageable than taking a snapshot, develop and fix missing things the next years. But not be able to rebase it to a newer kernel because kernel APIs have diverged too much.
Any my final though is that u-boot belongs to the basis we want to build something on. So it should be stabilized - but not changed too often...
In my opinion every software is the same. They all have bugs. So all of them need to be update able.
Well, this contradicts your idea of that there are no bugs if it passes the compile&boot test :)
when did I said that? Of course you can only be sure to find known bugs and issues. If you find a new one, advance your testing and be sure to never ship the same bug again.
If I update software, I have to make sure the update isn't making anything worse. So I have to test. If I master my testcases I don't have to care about frequent updates anymore. If my test process is good, I don't have to make a distinction between small bugfix updates or big version upgrades. They are both best tested and fulfill the same quality standards.
Yes, that is correct.
Where I see the next good situation for upgrading u-boot source code is when there is no longer a (horrible) mixture of old u-boot config and Kconfig where it sometimes needs experimentation to find out what should be configured where. I don't know how the status of 2018.05 is but 2017 u-boot wasn't much better than 2016.
While getting into mainline, they will tell you exactly what config option you have to move to Kconfig, now. If you have your board in mainline the community will convert the rest of config files to Kconfig for you!
Yes, that would be nice.
Anyways, if you think it is the best way and can do it I am fine with this. I just want to make sure that we are working on the most important things (from my overall view we have more than 10 times as many issues with kernel than with u-boot) and they do not end in a cul-de-sac.
Absolutely. It was my plan from the start to run mainline U-Boot and Linux on my Pyra. When ED asked for help in the latest newspost I thought, hell I should try to help him and start early. I don't want to annoy you or anyone else. All I can do is share my work early so maybe others can benefit. If it's not appropriate for your or EDs repository just tell me and I will stop the noise.
if you need write access at some point, please contact me.
or github
git://git.goldelico.com/gta04-uboot.git is mirrored to https://github.com/goldelico/gta04-uboot
I have a compiling tree, now. I am pretty sure it won't boot, but at least the compiler is happy.
I tried to login/register on https://dev.pyra-handheld.com but didn't got a mail till, now.
So I forked your repo on github and pushed a new branch with my rebase: https://github.com/bruenn/gta04-uboot/tree/v2018.05-pyra-v1
Nice. If I find time, I'll take a look into it.
Maybe we should pull it into http://git.goldelico.com/?p=gta04-uboot.git;a=heads so that it shows up as
letux-2018.05
Well, if that quick & dirty rebase is working for your other boards, sure take it.
Well, I always wonder why there is some "my board" and "your boards" notion. Letux OS is "our boards" and Pyra is one of ours. Of course everyone has favourites and not everyone has the same set of boards to really work and do tests.
Okay, maybe I have to explain myself a bit. The Pyra is my personal primary target. So that's my focus and that's why I am here. But of course I would like to help you to clean up the rest of the repository.
In my personal experience this mainlining stuff is very intrusive work and you are shifting code left and right. That's already stressful if you do it with your own code, because maintainers send you from left to right. But it is even more stressful if you do it with code from others in their repository. Not all people like aliens coming into their repository and start shifting code around. So I tried to be a little careful with that.
or alternatively as
work/patrick/letux-2018.05 I would prefer this. Because my target is to ultimately get rid of any
out tree patches for the Pyra. To reach there I will have to remove everything not Pyra related from my intermediate branch and then regroup the changes in small commits which I can send upstream one by one.
On that way I will create a lot of new branches and rebases.
That is how we do it for the letux kernel as well. There we have ca. 30 feature branches and merge them together for every release. Similar to linux-next.
These branches are cleaned up and tried to get upstream making them empty after a while.
Unfortunately some are not empty since 5 years...
You can get an idea from the names. <u-boot-base-version>-pyra-<rebase-version>: f.e.: v2018.05-pyra-v1 -> v2018.05-pyra-v2... v2018.07-rc1-pyra-v1.... Today I begun divide and conquer and removed beagle and gta files from v2018.05-pyra-v2. so my diff was shrinked from: 197 files changed, 13598 insertions(+), 74 deletions(-) to: 56 files changed, 2335 insertions(+), 74 deletions(-)
I wonder if it would be possible to do the same for the gta/beagle files while you are alredy working on this, so that the whole letux u-boot can finally be upstreamed? Letux OS is not a private project, but for the community.
I will have a look. I think I saw some stuff which could be merged together. Well, I wrote that last sentence last week. I hadn't much time since then but trying to look on the other boards too, was a bit confusing so I decided to divide and conquer. I will start with Pyra related files and tell you whenever I see something about the other boards. One thing: There are so many defconfig files which are perfect copies. Are they all necessary? Can we rename them to something common and reuse it for the shared boards? Another thing I saw is. You seem to never rebase your branches. So now we have 250 commits. Some of them are only adding debug printf() and others revert these again. These commits are not visible, when you diff agains mainline. However, while rebasing you have to take them with you. On "v2018.05-pyra-v3" I started to drop some of them.
To continue I have some questions: Which is the correct boot-scr/dtb/defconfig for the Pyra? uEnv-letux-cortex15+pyra.txt
this one.
uEnv-letux-cortex15.txt
Letux Cortex 15 is the CPU board (which is to be used for different projects as well and can even be booted stand-alone) and + pyra is for the combination with the Pyra mainboard.
The idea is to be able to replace the CPU board by another one as easyly as possible and not have to dig into the pyra components.
Therefore, please keep lc15 and pyra separated! Having just a single pyra board upstream but not lc15 makes this upgrade path more painful.
Good to know. I will try to prepare lc15 as the basis and pyra as a variant of it. Do we need all of this defconfig files: letux_gta15_4gb_defconfig letux_lc15_4gb_evm_defconfig pandora_pyra_lc15_4gb_defconfig letux_cortex15_4gb_defconfig
letux_gta15_defconfig letux_lc15_evm_defconfig pandora_pyra_lc15_defconfig letux_cortex15_defconfig
uEnv-letux-cortex8.txt
this is an am3358 board.
uEnv-omap5-uevm+pyra.txt uEnv-omap5-uevm.txt
this is the omap5evm and there was a prototype of the pyra mainboard connected to the omap5evm by cables.
OSD3358 is not relevant for the Pyra is it?
No, that is also the AM3358 chip (inside a module).
What is board/goldelico/cmd_monitor.c? I didn't found any reference within the u-boot repository.
That is a tool built into SPL which allows you to break into the serial boot process and have some very primitive console commands.
This is useful if a board can not access DRAM properly. But we don't need that regularity. Interesting.
and give you write access so that you can simply push.
For getting access, please register to http://projects.goldelico.com/p/gta04-uboot/ provide your public key in the user's settings and I can add you to the "Happy Crew" which gives you write access to the git repo.
Done.
Ok, you are now member of the happy crew!
Thanks, but still I am unable to fetch via ssh :-(. I will keep pushing to github until I find out whats wrong with my keys.
Small note: the webinterface doesn't except my ed25519 key. Maybe it's just a config option or upgrade away.
Seems to be too new for Indefero. Unfortunately, Indefero isn't maintained for a while.
For now, I generated a rsa one.
So please test. If it does not work, I have a debug procedure and we could always solve it.
BR and thans, Nikolaus
Hi Patrick,
Am 24.06.2018 um 20:16 schrieb patrick patrick@wylight.de:
On 18.06.2018 07:17, H. Nikolaus Schaller wrote:
Hi Patrick,
Am 18.06.2018 um 00:57 schrieb patrick patrick@wylight.de:
On 16.06.2018 13:28, H. Nikolaus Schaller wrote:
Hi Patrick,
Am 16.06.2018 um 01:18 schrieb patrick patrick@wylight.de:
On 15.06.2018 17:42, H. Nikolaus Schaller wrote:
> Am 15.06.2018 um 00:36 schrieb patrick patrick@wylight.de:
So this was a good point in time rebase and fix and extend the code. But then we did leave it as is. Especially because the config system was in the middle of being upgraded and there were experiments with device tree in u-boot. So we decided to "never touch a running system".
That's an interesting topic to discus, because my opinion is quite the
opposite. But I don't want to start an argument on my second day on this list so let's keep that discussion for the release party and in the mean time I try to persuade by action.
Yes, let's do it!
My argument is not a technical one but an organizational one... Or weighting usefulness vs. efforts.
And there I see that rebasing u-boot to every new release from upstream doesn't add many significant features, but takes a lot of testing time. Maybe I am a bit naive here but besides from booting, what do you have
to test? In the end the only u-boot feature you are using is one straight boot path.
No. There are upstream changes that may break your system and your board may boot, but not everything has been initialized in the same way the kernel relies on. For example we have some special initialization for the charger chip.
And the key problem we have with kernel development is that kernel maintainers do not accept everything. So there is a zombie state where upstream does not care about private work, because they don't see it.
I know, I have to maintain two out of tree kernel patches, too. The problem with these patches is, they are ugly hacks which could be done better. So until I find the time to clean them up correcty I have to rebase them regulary to keep them in sync with upstream.
Indeed. This is like weekly life with kernel.org :)
Fortunately, rebase conflicts are rare. Mainly with -rc1 only.
Therefore, if we wait until a big set of new features have accumulated and then do the rebase and testing once, it is a much better improvement for the invested time.
In my personal experience I made a big mistake, waiting to long to rebase so that rebasing costs me a lot of time.
Yes, it did cost us ca. 2 months to rebase 2013 to 2016.
Since all my code is mainline.
Ok, if you are happy to get to that point. We are hunting for this for years to get in the same state for the kernel but it is impossible.
All I do is compile and boot test once in a while. I don't have to ship new versions, but I know that if I had to I could immediately start without rebasing multiple iterations of u-boot first. Working on the latest version, has the same benefits as for the kernel:
- you have community support
- you can send your changes immediately to mainline
While getting them accepted can sometimes be a real pain, it is worth it in the end. You get code review for free! And in my experience we reduced my initial code to 30%. Since my board is in mainline it received 7 commits. Only two of them are from me. The rest was bug-fixes and global cleanups made by the community. All for free!
My key concern is that you don't get everything upstream. If you get it it is nice.
Even if I don't get everything upstream I can reduce the number of out of tree patches and with it the effort to maintain them.
For the kernel I see the reverse situation. Every new release brings significant improvements - either from upstream or by our own work to fill gaps (e.g. missing device drivers). For U-Boot we have almost no missing features because it does what it is designed for.
Therefore for the kernel, the rolling rebase scheme has turned out to be better manageable than taking a snapshot, develop and fix missing things the next years. But not be able to rebase it to a newer kernel because kernel APIs have diverged too much.
Any my final though is that u-boot belongs to the basis we want to build something on. So it should be stabilized - but not changed too often...
In my opinion every software is the same. They all have bugs. So all of them need to be update able.
Well, this contradicts your idea of that there are no bugs if it passes the compile&boot test :)
when did I said that? Of course you can only be sure to find known bugs and issues. If you find a new one, advance your testing and be sure to never ship the same bug again.
Maybe I misunderstood "All I do is compile and boot test once in a while."
If I update software, I have to make sure the update isn't making anything worse. So I have to test. If I master my testcases I don't have to care about frequent updates anymore. If my test process is good, I don't have to make a distinction between small bugfix updates or big version upgrades. They are both best tested and fulfill the same quality standards.
Yes, that is correct.
Where I see the next good situation for upgrading u-boot source code is when there is no longer a (horrible) mixture of old u-boot config and Kconfig where it sometimes needs experimentation to find out what should be configured where. I don't know how the status of 2018.05 is but 2017 u-boot wasn't much better than 2016.
While getting into mainline, they will tell you exactly what config option you have to move to Kconfig, now. If you have your board in mainline the community will convert the rest of config files to Kconfig for you!
Yes, that would be nice.
Anyways, if you think it is the best way and can do it I am fine with this. I just want to make sure that we are working on the most important things (from my overall view we have more than 10 times as many issues with kernel than with u-boot) and they do not end in a cul-de-sac.
Absolutely. It was my plan from the start to run mainline U-Boot and Linux on my Pyra. When ED asked for help in the latest newspost I thought, hell I should try to help him and start early. I don't want to annoy you or anyone else. All I can do is share my work early so maybe others can benefit. If it's not appropriate for your or EDs repository just tell me and I will stop the noise.
No, it is no noise. I just wanted to find out our own thought about it. In the meantime you have convinced me.
if you need write access at some point, please contact me.
> or github
git://git.goldelico.com/gta04-uboot.git is mirrored to https://github.com/goldelico/gta04-uboot
I have a compiling tree, now. I am pretty sure it won't boot, but at least the compiler is happy.
I tried to login/register on https://dev.pyra-handheld.com but didn't got a mail till, now.
So I forked your repo on github and pushed a new branch with my rebase: https://github.com/bruenn/gta04-uboot/tree/v2018.05-pyra-v1
Nice. If I find time, I'll take a look into it.
Maybe we should pull it into http://git.goldelico.com/?p=gta04-uboot.git;a=heads so that it shows up as
letux-2018.05
Well, if that quick & dirty rebase is working for your other boards, sure take it.
Well, I always wonder why there is some "my board" and "your boards" notion. Letux OS is "our boards" and Pyra is one of ours. Of course everyone has favourites and not everyone has the same set of boards to really work and do tests.
Okay, maybe I have to explain myself a bit. The Pyra is my personal primary target. So that's my focus and that's why I am here. But of course I would like to help you to clean up the rest of the repository.
In my personal experience this mainlining stuff is very intrusive work and you are shifting code left and right. That's already stressful if you do it with your own code, because maintainers send you from left to right. But it is even more stressful if you do it with code from others in their repository. Not all people like aliens coming into their repository and start shifting code around. So I tried to be a little careful with that.
Maybe I just wanted to keep U-Boot as it is because I already have to work with all these aspects with the kernel upstreaming.
or alternatively as
work/patrick/letux-2018.05 I would prefer this. Because my target is to ultimately get rid of any
out tree patches for the Pyra. To reach there I will have to remove everything not Pyra related from my intermediate branch and then regroup the changes in small commits which I can send upstream one by one.
On that way I will create a lot of new branches and rebases.
That is how we do it for the letux kernel as well. There we have ca. 30 feature branches and merge them together for every release. Similar to linux-next.
These branches are cleaned up and tried to get upstream making them empty after a while.
Unfortunately some are not empty since 5 years...
You can get an idea from the names. <u-boot-base-version>-pyra-<rebase-version>: f.e.: v2018.05-pyra-v1 -> v2018.05-pyra-v2... v2018.07-rc1-pyra-v1.... Today I begun divide and conquer and removed beagle and gta files from v2018.05-pyra-v2. so my diff was shrinked from: 197 files changed, 13598 insertions(+), 74 deletions(-) to: 56 files changed, 2335 insertions(+), 74 deletions(-)
I wonder if it would be possible to do the same for the gta/beagle files while you are alredy working on this, so that the whole letux u-boot can finally be upstreamed? Letux OS is not a private project, but for the community.
I will have a look. I think I saw some stuff which could be merged together.
Fine!
Well, I wrote that last sentence last week. I hadn't much time since then but trying to look on the other boards too, was a bit confusing so I decided to divide and conquer. I will start with Pyra related files and tell you whenever I see something about the other boards. One thing: There are so many defconfig files which are perfect copies. Are they all necessary? Can we rename them to something common and reuse it for the shared boards?
To be honest: I don't know. They may have been different names for historic reasons or there may have been some technical reason that it was not possible to build different variants with different configs. Maybe 2016.11 had still too much of the old non Kconfig stuff. May have changed now.
Another thing I saw is. You seem to never rebase your branches. So now we have 250 commits. Some of them are only adding debug printf() and others revert these again. These commits are not visible, when you diff agains mainline. However, while rebasing you have to take them with you. On "v2018.05-pyra-v3" I started to drop some of them.
Yes, that is ok!
This is also historic. Basically we did take our ugly pile of 2011.something and rebased once to 2016.8 (I think). Then fixed stuff. And rebased once to 2016.11 to get latest OneNAND support in.
All this comes from the pile-up source code management model. Not from the merge-cleaned-up-feature-branches model the letux kernel already has.
To continue I have some questions: Which is the correct boot-scr/dtb/defconfig for the Pyra? uEnv-letux-cortex15+pyra.txt
this one.
uEnv-letux-cortex15.txt
Letux Cortex 15 is the CPU board (which is to be used for different projects as well and can even be booted stand-alone) and + pyra is for the combination with the Pyra mainboard.
The idea is to be able to replace the CPU board by another one as easyly as possible and not have to dig into the pyra components.
Therefore, please keep lc15 and pyra separated! Having just a single pyra board upstream but not lc15 makes this upgrade path more painful.
Good to know. I will try to prepare lc15 as the basis and pyra as a variant of it. Do we need all of this defconfig files: letux_gta15_4gb_defconfig letux_lc15_4gb_evm_defconfig pandora_pyra_lc15_4gb_defconfig letux_cortex15_4gb_defconfig
letux_gta15_defconfig letux_lc15_evm_defconfig pandora_pyra_lc15_defconfig letux_cortex15_defconfig
If there is an easy way to merge all of them into a single one (or maybe two or three), let's do it.
uEnv-letux-cortex8.txt
this is an am3358 board.
uEnv-omap5-uevm+pyra.txt uEnv-omap5-uevm.txt
this is the omap5evm and there was a prototype of the pyra mainboard connected to the omap5evm by cables.
OSD3358 is not relevant for the Pyra is it?
No, that is also the AM3358 chip (inside a module).
What is board/goldelico/cmd_monitor.c? I didn't found any reference within the u-boot repository.
That is a tool built into SPL which allows you to break into the serial boot process and have some very primitive console commands.
This is useful if a board can not access DRAM properly. But we don't need that regularity. Interesting.
and give you write access so that you can simply push.
For getting access, please register to http://projects.goldelico.com/p/gta04-uboot/ provide your public key in the user's settings and I can add you to the "Happy Crew" which gives you write access to the git repo.
Done.
Ok, you are now member of the happy crew!
Thanks, but still I am unable to fetch via ssh :-(. I will keep pushing to github until I find out whats wrong with my keys.
Ah, my fault. There is a permissions bug on the server so that I have to manually trigger toe update of the ssh keys. Have done it now.
BR and thanks, Nikolaus
On Sa, 2018-06-16 at 01:18 +0200, patrick wrote:
Hi,
I tried to login/register on https://dev.pyra-handheld.com but didn't got a mail till, now.
This is weird. Checked your Spam folder? I just tried with a new email address and I received the confirmation / activation mail right away.
It also seems to have worked for other users who registered.
On Do, 2018-06-14 at 23:55 +0200, aTc wrote:
Okay, so in this case, we can probably scrap that U-Boot and either use and improve the Letux one or build a new one completely.
As the menu will be done with a mini-kernel, it doesn't need to do a lot... except for configuring some stuff and booting the mini-kernel.
On 06/14/2018 04:32 AM, Michael Mrozek wrote:
This question is probably mostly aimed at aTc:
Right now, you only provide precompiled U-Boot binaries in the OS. Nowhere on gitlab have I found where the sources for those are.
I think the current one is based on the one here https://dev.pyra-handheld.com/notaz/pyra-u-boot
Im not entirely sure, because, as with the kernel, there have been quite a few different versions of the pyra uboot. I wanted to have a bootmenu, and an easy way to have the os configure boot options for multiple kernels, so i had a version of the letux uboot with extlinux enabled, zmatt did some fixes , and then notaz took all of the stuff and added a few more things, and it ended up on there. Not much has happened to it since then. It's probably horribly out of date with the letux uboot now.
-
aTc -
H. Nikolaus Schaller -
Michael Mrozek -
Mr C Camacho -
patrick -
Tony Lindgren