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

2014-08-21 11:31 GMT+04:00 Guillaume Gardet :

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

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:

...

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

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:

...

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

Le 21/08/2014 14:11, Matwey V. Kornilov a écrit :

2014-08-21 16:07 GMT+04:00 Guillaume Gardet :

...

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 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

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

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 :

...

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

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

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

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

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