[opensuse-arm] U-Boot v2014.07 - volunteers?
Hi, Handling a recent SR, I noticed that our Base:System u-boot is still at v2014.04. Some sun7i stuff landed in v2014.07, so our patches should hopefully start to shrink. https://build.opensuse.org/package/show/Base:System/u-boot I'm a bit preoccupied with kernel work already - is there anyone who can take on updating the package? Also a heads-up that for the next release, v2014.10, they have switched to Kconfig, which will then require us to modify build commands from ..._config to ..._defconfig. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
01.08.2014 18:00, Andreas Färber пишет:
Hi,
Handling a recent SR, I noticed that our Base:System u-boot is still at v2014.04.
I think it is worth to start with v2014.10-rc1 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
19.08.2014 19:56, Matwey V. Kornilov пишет:
01.08.2014 18:00, Andreas Färber пишет:
Hi,
Handling a recent SR, I noticed that our Base:System u-boot is still at v2014.04.
I think it is worth to start with v2014.10-rc1
I am trying to do it here: https://build.opensuse.org/project/monitor/home:matwey:branches:Base:System Now I need a hint what is to do with: [ 309s] ld.bfd: address 0x2026c40 of u-boot-spl section `.machine_param' is not within region `.sram' [ 309s] ld.bfd: u-boot-spl section `.bss' will not fit in region `.sram' [ 309s] ld.bfd: address 0x2026c40 of u-boot-spl section `.machine_param' is not within region `.sram' [ 309s] ld.bfd: address 0x2026c40 of u-boot-spl section `.machine_param' is not within region `.sram' [ 309s] ld.bfd: region `.sram' overflowed by 88 bytes -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 20.08.2014 19:04, schrieb Matwey V. Kornilov:
19.08.2014 19:56, Matwey V. Kornilov пишет:
01.08.2014 18:00, Andreas Färber пишет:
Handling a recent SR, I noticed that our Base:System u-boot is still at v2014.04.
I think it is worth to start with v2014.10-rc1
I am trying to do it here:
https://build.opensuse.org/project/monitor/home:matwey:branches:Base:System
Stephan had started looking into v2014.07 but also ran into issues with patches. Did you find out what to do about Cubox-i and sunxi?
Now I need a hint what is to do with:
[ 309s] ld.bfd: address 0x2026c40 of u-boot-spl section `.machine_param' is not within region `.sram' [ 309s] ld.bfd: u-boot-spl section `.bss' will not fit in region `.sram' [ 309s] ld.bfd: address 0x2026c40 of u-boot-spl section `.machine_param' is not within region `.sram' [ 309s] ld.bfd: address 0x2026c40 of u-boot-spl section `.machine_param' is not within region `.sram' [ 309s] ld.bfd: region `.sram' overflowed by 88 bytes
I think I reported something similar for an earlier version - most likely the Beagle'ish MLO patch that adds ext4 support to the SPL needs to be disabled until we have a better solution such as disabling FAT. To be clear, I am suggesting to revert any weird hacks that break the build until their authors care to properly submit upstream their changes. (Guillaume luckily came up with some new hack to fix the old hack last time, but apparently we still don't have a real solution.) The only patches "really" needed are the config patches to allow for raw initrd etc.; hardware-enabling patches (cubox, sunxi) could be limited to individual boards where not done already. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, Le 20/08/2014 22:34, Andreas Färber a écrit :
19.08.2014 19:56, Matwey V. Kornilov пишет:
01.08.2014 18:00, Andreas Färber пишет:
Handling a recent SR, I noticed that our Base:System u-boot is still at v2014.04. I think it is worth to start with v2014.10-rc1
I am trying to do it here:
https://build.opensuse.org/project/monitor/home:matwey:branches:Base:System Stephan had started looking into v2014.07 but also ran into issues with
Am 20.08.2014 19:04, schrieb Matwey V. Kornilov: patches. Did you find out what to do about Cubox-i and sunxi?
Is it mainlined now or not? I think some times ago Dirk said to drop sunxi patches from Base:System and handle them at a project level. Dirk, could you confirm, please?
Now I need a hint what is to do with:
[ 309s] ld.bfd: address 0x2026c40 of u-boot-spl section `.machine_param' is not within region `.sram' [ 309s] ld.bfd: u-boot-spl section `.bss' will not fit in region `.sram' [ 309s] ld.bfd: address 0x2026c40 of u-boot-spl section `.machine_param' is not within region `.sram' [ 309s] ld.bfd: address 0x2026c40 of u-boot-spl section `.machine_param' is not within region `.sram' [ 309s] ld.bfd: region `.sram' overflowed by 88 bytes I think I reported something similar for an earlier version - most likely the Beagle'ish MLO patch that adds ext4 support to the SPL needs to be disabled until we have a better solution such as disabling FAT.
Disabled where not needed, otherwise boards won't boot anymore.
To be clear, I am suggesting to revert any weird hacks that break the build until their authors care to properly submit upstream their changes. (Guillaume luckily came up with some new hack to fix the old hack last time, but apparently we still don't have a real solution.)
I started to make MLO-EXT2 patch better (upstreamable) some times ago but did not have time to test it.
The only patches "really" needed are the config patches to allow for raw initrd etc.; hardware-enabling patches (cubox, sunxi) could be limited to individual boards where not done already.
I agree. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
2014-08-21 11:31 GMT+04:00 Guillaume Gardet <guillaume.gardet@free.fr>:
Is it mainlined now or not? I think some times ago Dirk said to drop sunxi patches from Base:System and handle them at a project level. Dirk, could you confirm, please?
Mele_A1000 and Hyundai_A7HD are missed from upstream u-boot. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 21/08/2014 09:40, Matwey V. Kornilov a écrit :
2014-08-21 11:31 GMT+04:00 Guillaume Gardet<guillaume.gardet@free.fr>:
Is it mainlined now or not? I think some times ago Dirk said to drop sunxi patches from Base:System and handle them at a project level. Dirk, could you confirm, please? Mele_A1000 and Hyundai_A7HD are missed from upstream u-boot.
I think it would be best to handle non upstream u-boot boards separately and only keep upstream boards in u-boot from Base:System. What do you think about that? I reworked our EXT2 support for MLO (SPL for OMAP) to ease upstreaming. I based my work on Matwey update (2014.10-rc1). See: https://build.opensuse.org/project/monitor/home:Guillaume_G:branches:Base:Sy... It would be nice if people could test it. I already tested it successfully on Beagleboard xM and Pandaboard. Not sure which boards also used previous mlo-ext2 patch and thus would need some tests (and maybe patches). Maybe beaglebone. Comments on patches are also welcome before I send a first version upstream. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 21.08.2014 13:26, schrieb Guillaume Gardet:
Le 21/08/2014 09:40, Matwey V. Kornilov a écrit :
2014-08-21 11:31 GMT+04:00 Guillaume Gardet<guillaume.gardet@free.fr>:
Is it mainlined now or not? I think some times ago Dirk said to drop sunxi patches from Base:System and handle them at a project level. Dirk, could you confirm, please? Mele_A1000 and Hyundai_A7HD are missed from upstream u-boot.
I think it would be best to handle non upstream u-boot boards separately and only keep upstream boards in u-boot from Base:System. What do you think about that?
+1 We already have a Contrib:sunxi, where we could place it. In v2014.07 however, only Cubietruck was present, not Cubieboard and Cubieboard2, for which - unlike Mele and Hyundai - we have JeOS images somewhere.
I reworked our EXT2 support for MLO (SPL for OMAP) to ease upstreaming. I based my work on Matwey update (2014.10-rc1). See: https://build.opensuse.org/project/monitor/home:Guillaume_G:branches:Base:Sy...
About v2014.10-rc1 I'm more doubtful. To build JeOS images, we need to submit u-boot to Factory, so Base:System and Factory(:ARM) will be pretty much the same all the time. So I'm thinking it may make sense to update Base:System to the latest stable only, which still is v2014.07, and do the v2014.10-rc1 in, e.g., devel:ARM:Factory. If we put the resulting u-boot on an SD card it is less of a problem if something in the -rc breaks; but for flashing U-Boot, bricking the device is a risk. So I see this similar to keeping Kernel:HEAD separate from Factory. Last time I checked, there was no real OpenOCD package in OBS (only some old one in a home:), and it requires JTAG hardware, connectors on the board and config files matching the board. Opinions? Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
2014-08-21 15:51 GMT+04:00 Andreas Färber <afaerber@suse.de>:
I think it would be best to handle non upstream u-boot boards separately and only keep upstream boards in u-boot from Base:System. What do you think about that?
+1
Then we would be able to keep different specific versions of u-boot, but this should be an exception but not the rule. So the final goal is to have nice upstream u-boot (as well as the linux kernel).
We already have a Contrib:sunxi, where we could place it. In v2014.07 however, only Cubietruck was present, not Cubieboard and Cubieboard2,
Cubietruck is the newest version AFAIK.
I reworked our EXT2 support for MLO (SPL for OMAP) to ease upstreaming. I based my work on Matwey update (2014.10-rc1). See: https://build.opensuse.org/project/monitor/home:Guillaume_G:branches:Base:Sy...
About v2014.10-rc1 I'm more doubtful. To build JeOS images, we need to submit u-boot to Factory, so Base:System and Factory(:ARM) will be pretty much the same all the time. So I'm thinking it may make sense to update Base:System to the latest stable only, which still is v2014.07, and do the v2014.10-rc1 in, e.g., devel:ARM:Factory. If we put the resulting u-boot on an SD card it is less of a problem if something in the -rc breaks; but for flashing U-Boot, bricking the device is a risk. So I see this similar to keeping Kernel:HEAD separate from Factory.
I did -rc just because I am so slow and thought that 2014.10 will be released to the moment when I will have sorted the patches.
Last time I checked, there was no real OpenOCD package in OBS (only some old one in a home:), and it requires JTAG hardware, connectors on the board and config files matching the board.
https://build.opensuse.org/package/show/openSUSE:Factory/openocd -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 21/08/2014 13:51, Andreas Färber a écrit :
Am 21.08.2014 13:26, schrieb Guillaume Gardet:
Le 21/08/2014 09:40, Matwey V. Kornilov a écrit :
2014-08-21 11:31 GMT+04:00 Guillaume Gardet<guillaume.gardet@free.fr>:
Is it mainlined now or not? I think some times ago Dirk said to drop sunxi patches from Base:System and handle them at a project level. Dirk, could you confirm, please? Mele_A1000 and Hyundai_A7HD are missed from upstream u-boot.
I think it would be best to handle non upstream u-boot boards separately and only keep upstream boards in u-boot from Base:System. What do you think about that? +1
We already have a Contrib:sunxi, where we could place it. In v2014.07 however, only Cubietruck was present, not Cubieboard and Cubieboard2, for which - unlike Mele and Hyundai - we have JeOS images somewhere.
I reworked our EXT2 support for MLO (SPL for OMAP) to ease upstreaming. I based my work on Matwey update (2014.10-rc1). See: https://build.opensuse.org/project/monitor/home:Guillaume_G:branches:Base:Sy... About v2014.10-rc1 I'm more doubtful. To build JeOS images, we need to submit u-boot to Factory, so Base:System and Factory(:ARM) will be pretty much the same all the time. So I'm thinking it may make sense to update Base:System to the latest stable only, which still is v2014.07, and do the v2014.10-rc1 in, e.g., devel:ARM:Factory. If we put the resulting u-boot on an SD card it is less of a problem if something in the -rc breaks; but for flashing U-Boot, bricking the device is a risk. So I see this similar to keeping Kernel:HEAD separate from Factory.
There are 2 solutions: * have a seprate (devel) project for -rc versions and keep Base:System as a stable repo (in sync with Factory) * Use Base:System as a devel project and submit only stable versions to Factory. The thing is we must be able to test -rc versions. Otherwise stable (non tested) versions may not work. The easiest way is to build JeOS images using -rc images. To me, it was the purpose of Factory, but now Factory is becoming a rolling (stable) release, so we should have another project for our tests (devel:ARM:Factory for example, but which build JeOS images).
Last time I checked, there was no real OpenOCD package in OBS (only some old one in a home:), and it requires JTAG hardware, connectors on the board and config files matching the board.
openocd is available in hardware and Factory projects. But I guess you need some hardware (JTAG, ...). Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
2014-08-21 16:07 GMT+04:00 Guillaume Gardet <guillaume.gardet@free.fr>:
The thing is we must be able to test -rc versions. Otherwise stable (non tested) versions may not work. The easiest way is to build JeOS images using -rc images. To me, it was the purpose of Factory, but now Factory is becoming a rolling (stable) release, so we should have another project for our tests (devel:ARM:Factory for example, but which build JeOS images).
The same issue is with kernel. We need JeOS images with kernel -rc for testing. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 21/08/2014 14:11, Matwey V. Kornilov a écrit :
2014-08-21 16:07 GMT+04:00 Guillaume Gardet <guillaume.gardet@free.fr>:
The thing is we must be able to test -rc versions. Otherwise stable (non tested) versions may not work. The easiest way is to build JeOS images using -rc images. To me, it was the purpose of Factory, but now Factory is becoming a rolling (stable) release, so we should have another project for our tests (devel:ARM:Factory for example, but which build JeOS images). The same issue is with kernel. We need JeOS images with kernel -rc for testing.
So, we could use devel:ARM:Factory to test u-boot and kernel (from kernel:HEAD?) with JeOS images. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 21.08.2014 16:27, Guillaume Gardet wrote:
So, we could use devel:ARM:Factory to test u-boot and kernel (from kernel:HEAD?) with JeOS images.
Would be great, given that kernel from Kernel:HEAD is already built. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 25.08.14 11:07, Matwey V. Kornilov wrote:
On 21.08.2014 16:27, Guillaume Gardet wrote:
So, we could use devel:ARM:Factory to test u-boot and kernel (from kernel:HEAD?) with JeOS images.
Would be great, given that kernel from Kernel:HEAD is already built.
How about a new subproject like "devel:ARM:Factory:Unstable" that simply links the JeOS package (plus internal self-links) and adds Base:System as well as Kernel:HEAD to the repo list? There's a good chance we'd have to have a cron job that manually recreates the patch on top of that link in case openSUSE:Factory:ARM/JeOS changes, but I guess that's reasonably possible to do. I guess for dtb-source we're best off to have it built as part of Kernel:HEAD as well. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 25/08/2014 11:22, Alexander Graf a écrit :
On 25.08.14 11:07, Matwey V. Kornilov wrote:
On 21.08.2014 16:27, Guillaume Gardet wrote:
So, we could use devel:ARM:Factory to test u-boot and kernel (from kernel:HEAD?) with JeOS images. Would be great, given that kernel from Kernel:HEAD is already built.
How about a new subproject like "devel:ARM:Factory:Unstable" that simply links the JeOS package (plus internal self-links) and adds Base:System as well as Kernel:HEAD to the repo list?
Sounds good to me.
There's a good chance we'd have to have a cron job that manually recreates the patch on top of that link in case openSUSE:Factory:ARM/JeOS changes, but I guess that's reasonably possible to do.
I guess for dtb-source we're best off to have it built as part of Kernel:HEAD as well.
It is better to have DTB matching kernel used but it is not mandatory. Maybe just rebuild DTB in this new project so that it uses DTS from Kernel:HEAD? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 25.08.14 11:27, Guillaume Gardet wrote:
Le 25/08/2014 11:22, Alexander Graf a écrit :
On 25.08.14 11:07, Matwey V. Kornilov wrote:
On 21.08.2014 16:27, Guillaume Gardet wrote:
So, we could use devel:ARM:Factory to test u-boot and kernel (from kernel:HEAD?) with JeOS images. Would be great, given that kernel from Kernel:HEAD is already built.
How about a new subproject like "devel:ARM:Factory:Unstable" that simply links the JeOS package (plus internal self-links) and adds Base:System as well as Kernel:HEAD to the repo list?
Sounds good to me.
There's a good chance we'd have to have a cron job that manually recreates the patch on top of that link in case openSUSE:Factory:ARM/JeOS changes, but I guess that's reasonably possible to do.
I guess for dtb-source we're best off to have it built as part of Kernel:HEAD as well.
It is better to have DTB matching kernel used but it is not mandatory. Maybe just rebuild DTB in this new project so that it uses DTS from Kernel:HEAD?
That's what I would've proposed originally. I guess considering that the device tree should move out of the kernel source it does make sense. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 21.08.2014 14:11, schrieb Matwey V. Kornilov:
2014-08-21 16:07 GMT+04:00 Guillaume Gardet <guillaume.gardet@free.fr>:
The thing is we must be able to test -rc versions. Otherwise stable (non tested) versions may not work. The easiest way is to build JeOS images using -rc images. To me, it was the purpose of Factory, but now Factory is becoming a rolling (stable) release, so we should have another project for our tests (devel:ARM:Factory for example, but which build JeOS images).
The same issue is with kernel. We need JeOS images with kernel -rc for testing.
Hm, take a look at https://build.opensuse.org/monitor - we're really low on armv7l build power. Last night we had six build hosts, today ten with 22 worker VMs. People branching kernel package add to that problem. (I just asked Bamvor to drop a Kernel:stable branch with no diff.) We did not manage to get both kernel-default and kernel-lpae built before the next Kernel:HEAD update. (Which possibly is why they didn't get published.) So not sure how many JeOS combinations of kernel and U-Boot we can realistically build concurrently. Once we have a working JeOS for a board, people could just update to Kernel:HEAD from there themselves. For new boards where the kernel does not yet boot we simply can't create new JeOS images outside Contrib:* today. For U-Boot testing I agree it would make sense to have images built. Dropping the downstream Raspberry Pi kernel and merging :upstream into Contrib:RaspberryPi would seem like a nice cleanup btw. Requires the fixed kernel to get built, of course. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 21/08/2014 14:49, Andreas Färber a écrit :
Am 21.08.2014 14:11, schrieb Matwey V. Kornilov:
2014-08-21 16:07 GMT+04:00 Guillaume Gardet <guillaume.gardet@free.fr>:
The thing is we must be able to test -rc versions. Otherwise stable (non tested) versions may not work. The easiest way is to build JeOS images using -rc images. To me, it was the purpose of Factory, but now Factory is becoming a rolling (stable) release, so we should have another project for our tests (devel:ARM:Factory for example, but which build JeOS images). The same issue is with kernel. We need JeOS images with kernel -rc for testing. Hm, take a look at https://build.opensuse.org/monitor - we're really low on armv7l build power. Last night we had six build hosts, today ten with 22 worker VMs. People branching kernel package add to that problem. (I just asked Bamvor to drop a Kernel:stable branch with no diff.)
We did not manage to get both kernel-default and kernel-lpae built before the next Kernel:HEAD update. (Which possibly is why they didn't get published.)
So not sure how many JeOS combinations of kernel and U-Boot we can realistically build concurrently. Once we have a working JeOS for a board, people could just update to Kernel:HEAD from there themselves. For new boards where the kernel does not yet boot we simply can't create new JeOS images outside Contrib:* today. For U-Boot testing I agree it would make sense to have images built.
Ok.
Dropping the downstream Raspberry Pi kernel and merging :upstream into Contrib:RaspberryPi would seem like a nice cleanup btw. Requires the fixed kernel to get built, of course.
Would be nice to check if omxplayer (hardware accelerated video decoder availaible in packman repo) is working fine with upstream kernel. Otherwise, we should keep downstream kernel to keep this main feature of the raspberry pi. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 21.08.2014 15:01, schrieb Guillaume Gardet:
Le 21/08/2014 14:49, Andreas Färber a écrit :
Dropping the downstream Raspberry Pi kernel and merging :upstream into Contrib:RaspberryPi would seem like a nice cleanup btw. Requires the fixed kernel to get built, of course.
Would be nice to check if omxplayer (hardware accelerated video decoder availaible in packman repo) is working fine with upstream kernel. Otherwise, we should keep downstream kernel to keep this main feature of the raspberry pi.
Is that really a criteria? packman is not part of openSUSE, right? My point here was that in order to build "real" JeOS images (which didn't build last time I checked) Alex linked Kernel:HEAD kernel-source into Contrib:RaspberryPi:upstream, because unfortunately that otherwise inherits kernel-source from Contrib:RaspberryPi, which is the downstream kernel. I don't mind keeping the downstream kernel, but in that case we need a different project setup. For instance, Contrib:RaspberryPi:downstream. dtb-source is the other package dependent on the right kernel-source. Or maybe we can just get JeOS-RaspberryPi into Factory:ARM now and drop :upstream? The firmware blobs for the FAT partition are probably not in Factory though? Could we submit them to Factory:ARM? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 21/08/2014 15:14, Andreas Färber a écrit :
Am 21.08.2014 15:01, schrieb Guillaume Gardet:
Dropping the downstream Raspberry Pi kernel and merging :upstream into Contrib:RaspberryPi would seem like a nice cleanup btw. Requires the fixed kernel to get built, of course. Would be nice to check if omxplayer (hardware accelerated video decoder availaible in packman repo) is working fine with upstream kernel. Otherwise, we should keep downstream kernel to keep this main feature of
Le 21/08/2014 14:49, Andreas Färber a écrit : the raspberry pi. Is that really a criteria? packman is not part of openSUSE, right?
We should give to our users a good experience. No? ;)
My point here was that in order to build "real" JeOS images (which didn't build last time I checked) Alex linked Kernel:HEAD kernel-source into Contrib:RaspberryPi:upstream, because unfortunately that otherwise inherits kernel-source from Contrib:RaspberryPi, which is the downstream kernel.
I don't mind keeping the downstream kernel, but in that case we need a different project setup. For instance, Contrib:RaspberryPi:downstream.
Could be a solution.
dtb-source is the other package dependent on the right kernel-source.
Or maybe we can just get JeOS-RaspberryPi into Factory:ARM now and drop :upstream? The firmware blobs for the FAT partition are probably not in Factory though? Could we submit them to Factory:ARM?
I guess we could. But we will have to add it to openSUSE:13.2:Ports later. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Andreas Färber <afaerber@suse.de> writes:
My point here was that in order to build "real" JeOS images (which didn't build last time I checked) Alex linked Kernel:HEAD kernel-source into Contrib:RaspberryPi:upstream, because unfortunately that otherwise inherits kernel-source from Contrib:RaspberryPi, which is the downstream kernel.
If you just need a particular package from another project you could add the project to the repository path or use an aggregate to import the package, instead of building another copy of it. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 21.08.2014 16:49, Andreas Färber wrote:
Hm, take a look at https://build.opensuse.org/monitor - we're really low on armv7l build power. Last night we had six build hosts, today ten with 22 worker VMs. People branching kernel package add to that problem. (I just asked Bamvor to drop a Kernel:stable branch with no diff.)
Maybe open donations company and buy more hardware? -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 25.08.14 11:07, Matwey V. Kornilov wrote:
On 21.08.2014 16:49, Andreas Färber wrote:
Hm, take a look at https://build.opensuse.org/monitor - we're really low on armv7l build power. Last night we had six build hosts, today ten with 22 worker VMs. People branching kernel package add to that problem. (I just asked Bamvor to drop a Kernel:stable branch with no diff.)
Maybe open donations company and buy more hardware?
The scripts that reset our existing (not perfectly stable) machines were just not properly tuned. I hope I've managed to cover all cases now - we're on full build power for a few days now and the ARM queue is basically empty. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 25.08.2014 11:12, schrieb Alexander Graf:
On 25.08.14 11:07, Matwey V. Kornilov wrote:
On 21.08.2014 16:49, Andreas Färber wrote:
Hm, take a look at https://build.opensuse.org/monitor - we're really low on armv7l build power. Last night we had six build hosts, today ten with 22 worker VMs. People branching kernel package add to that problem. (I just asked Bamvor to drop a Kernel:stable branch with no diff.)
Maybe open donations company and buy more hardware?
The scripts that reset our existing (not perfectly stable) machines were just not properly tuned. I hope I've managed to cover all cases now - we're on full build power for a few days now and the ARM queue is basically empty.
Actually I also got a few more delete requests for kernel branches accepted, and Kernel:HEAD is no longer building due to 3.17 update. ;) Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, Am 21.08.2014 09:31, schrieb Guillaume Gardet:
Hi,
Le 20/08/2014 22:34, Andreas Färber a écrit :
Am 20.08.2014 19:04, schrieb Matwey V. Kornilov:
19.08.2014 19:56, Matwey V. Kornilov пишет:
01.08.2014 18:00, Andreas Färber пишет: I think it is worth to start with v2014.10-rc1
I am trying to do it here:
https://build.opensuse.org/project/monitor/home:matwey:branches:Base:System
Stephan had started looking into v2014.07 but also ran into issues with patches. Did you find out what to do about Cubox-i and sunxi?
This is about Cubox-i. I think it is okay to ignore the cubox-i patch when you need to update u-boot. To my knowledge there is not a port ofa more recent than 2014-04 uboot for it, and it is not something I could do. It may be wise, for cubox-i to stay with an older version of uboot now, especially since similar hardware like the HummingBoard are so far working only with an older uboot provided by SolidRun. I believe that is the version the cubox-i port will have to stay on for a while. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJT+GXSAAoJEAgPKSyhCrKU6WYH/1TQt8qdR87aneF7RmynhT7B vcvdRH8rUzoNJ5Q/riTU9fDg7jNwzXhfS4GXuj0vUalNR6kiBOv6cOabp2CGtIuI OngPmDafunVAm6ZBkHQSVEMkJd6NRfURAKskcC27iO7L/ld8vREtVN5D2gbCwqk+ KFa5umXUSD1sBcxtHpwwDoSUL8TBsfYC8WPa5C7tsBfAHvxeGcOKmhp04ub+Qjbq D6bFUE0PnDfKB5w1vIU4wXPa5DONpuwwVv/ZnVAei7JZOAPsws570KB4Mnzhaf0r 9DoFAMuip7CMLbl7hpER0DwRJMpWp3iaZzi5gOcSTD8Z45LmTfz/H0x/ZYyJ6jo= =kRQU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, On Wed, Aug 20, 2014 at 10:34:51PM +0200, Andreas Färber wrote:
Stephan had started looking into v2014.07 but also ran into issues with patches. Did you find out what to do about Cubox-i and sunxi?
Just for the record: Due to lack of time and most importantly, because Matwey and Guillaume do a great job on this, I have deleted my branch and stopped working on updating u-boot. -- Bye, Stephan Barth SUSE MaintenanceSecurity - SUSE LINUX Products GmbH GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (7)
-
Alexander Graf -
Andreas Färber -
Andreas Schwab -
Guillaume Gardet -
Josua Mayer -
Matwey V. Kornilov -
Stephan Barth