Re: link time optimization testing - Was: Re: asus/p2b - not enough space in cbfs for default build since i440bx bootblock console enable
On 5/25/21, Paul Menzel <pmenzel@molgen.mpg.de> wrote:
Dear Branden,
Am 22.05.21 um 20:03 schrieb Branden Waldner:
On 5/21/21, Arthur Heymans <arthur@aheymans.xyz> wrote:
Thanks for sharing your findings. The flash is 256K big, which is quite small these days. When building coreboot with default settings but without a payload I find that there is 69K empty space left for payloads.
Some future developments I have been working on might give a bit more breathing space. - I want to make romstage optional and include the sources in the bootblock: That should shave off roughly 10K of romstage. - I have compressing postcar working (maybe you can also disable the postcar console to reduce size). That's also 2-3k size gains at likely the const of a tiny bit of boot performance on this platform. - I also have some WIP code to merge postcar into ramstage which would save 15k.
Maybe on coreboot release 4.15 you will have a better time building a fully working image with the default configuration.
I didn't realize there was development going on to save rom space, that's good to know.
I just built the asus/p2b from commit d981c490 (mb/google/mancomb: Enable some PCIe power saving features) with the Debian sid/unstable toolchain (gcc (Debian 10.2.1-6) 10.2.1 20210110).
There, wasn’t enough space to add SeaBIOS’ configuration file to CBFS. Not setting `INCLUDE_CONFIG_FILE`, there wasn’t any error, the coreboot image built fine.
``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 17336 none cpu_microcode_blob.bin 0x44c0 microcode 83968 none fallback/ramstage 0x18d00 stage 53376 LZMA (112168 decompressed) build_info 0x25e00 raw 89 none fallback/dsdt.aml 0x25e80 raw 5514 none cmos_layout.bin 0x27440 cmos_layout 704 none fallback/postcar 0x27740 stage 16888 none fallback/payload 0x2b980 simple elf 69886 none (empty) 0x3cac0 null 1956 none bootblock 0x3d280 bootblock 11088 none ```
Building with Jacob’s link time optimization changes [1], which he thankfully rebased, saved 13 kB, so the configuration file would fit in too.
``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 14752 none cpu_microcode_blob.bin 0x3ac0 microcode 83968 none fallback/ramstage 0x18300 stage 46277 LZMA (95496 decompressed) build_info 0x23840 raw 89 none fallback/dsdt.aml 0x238c0 raw 5514 none cmos_layout.bin 0x24e80 cmos_layout 704 none fallback/postcar 0x25180 stage 14872 none fallback/payload 0x28c00 simple elf 69886 none (empty) 0x39d40 null 15012 none bootblock 0x3d800 bootblock 9664 none ```
(If you have a recovery option and some spare time, it’d be great if you tested the LTO patches.)
I could probably test them out, though I'm not sure I'll get around to it right away. Does the patch set require anything special? It looks like it just uses a Kconfig to add the choice to use the LTO compiler options. Does it work with the coreboot crossgcc or should I try using the system compiler on the build machine like you did (Debian sid x86_64), or maybe it would be best to try both? My recovery method isn't very good right now though. If I've got a boot failure I change the rom to a known good one and hot swap back to the chip with the bad rom to reflash it. It's pretty annoying, but I haven't messed up yet. I did try to get some (cheap) zif adapter sockets, but they didn't work out for me - not enough space and they don't seat in a socket, they seem to be meant to be soldered to a board, not used in a socket. I haven't had much luck in finding options for recovery. Ideally I'd like something like the dual switched bios in the old wiki but toggle-able electronically ie. gpio pin from spare router w/ Openwrt. That sounds like a lot of work though and I never managed to find much online as examples.
Kind regards,
Paul
[1]: https://review.coreboot.org/c/coreboot/+/40815/ (whole series)
Branden
Dear Branden, Am 26.05.21 um 04:25 schrieb Branden Waldner:
On 5/25/21, Paul Menzel wrote:
Am 22.05.21 um 20:03 schrieb Branden Waldner:
On 5/21/21, Arthur Heymans <arthur@aheymans.xyz> wrote:
Thanks for sharing your findings. The flash is 256K big, which is quite small these days. When building coreboot with default settings but without a payload I find that there is 69K empty space left for payloads.
Some future developments I have been working on might give a bit more breathing space. - I want to make romstage optional and include the sources in the bootblock: That should shave off roughly 10K of romstage. - I have compressing postcar working (maybe you can also disable the postcar console to reduce size). That's also 2-3k size gains at likely the const of a tiny bit of boot performance on this platform. - I also have some WIP code to merge postcar into ramstage which would save 15k.
Maybe on coreboot release 4.15 you will have a better time building a fully working image with the default configuration.
I didn't realize there was development going on to save rom space, that's good to know.
I just built the asus/p2b from commit d981c490 (mb/google/mancomb: Enable some PCIe power saving features) with the Debian sid/unstable toolchain (gcc (Debian 10.2.1-6) 10.2.1 20210110).
There, wasn’t enough space to add SeaBIOS’ configuration file to CBFS. Not setting `INCLUDE_CONFIG_FILE`, there wasn’t any error, the coreboot image built fine.
``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 17336 none cpu_microcode_blob.bin 0x44c0 microcode 83968 none fallback/ramstage 0x18d00 stage 53376 LZMA (112168 decompressed) build_info 0x25e00 raw 89 none fallback/dsdt.aml 0x25e80 raw 5514 none cmos_layout.bin 0x27440 cmos_layout 704 none fallback/postcar 0x27740 stage 16888 none fallback/payload 0x2b980 simple elf 69886 none (empty) 0x3cac0 null 1956 none bootblock 0x3d280 bootblock 11088 none ```
Building with Jacob’s link time optimization changes [1], which he thankfully rebased, saved 13 kB, so the configuration file would fit in too.
``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 14752 none cpu_microcode_blob.bin 0x3ac0 microcode 83968 none fallback/ramstage 0x18300 stage 46277 LZMA (95496 decompressed) build_info 0x23840 raw 89 none fallback/dsdt.aml 0x238c0 raw 5514 none cmos_layout.bin 0x24e80 cmos_layout 704 none fallback/postcar 0x25180 stage 14872 none fallback/payload 0x28c00 simple elf 69886 none (empty) 0x39d40 null 15012 none bootblock 0x3d800 bootblock 9664 none ```
(If you have a recovery option and some spare time, it’d be great if you tested the LTO patches.)
I could probably test them out, though I'm not sure I'll get around to it right away.
No hurry.
Does the patch set require anything special? It looks like it just uses a Kconfig to add the choice to use the LTO compiler options.
Sorry, I only noted “(whole series)” below at the reference. You need the changes listed on the right side in Gerrit. Gerrit’s download options allow you to fetch those with one command.
Does it work with the coreboot crossgcc or should I try using the system compiler on the build machine like you did (Debian sid x86_64), or maybe it would be best to try both?
More tests are always welcome, but coreboot’s crossgcc should work.
My recovery method isn't very good right now though. If I've got a boot failure I change the rom to a known good one and hot swap back to the chip with the bad rom to reflash it. It's pretty annoying, but I haven't messed up yet.
Speaking from experience, three chips would be better. ;-) But, I used the same method for years, and there are worse methods (if no socket is there).
I did try to get some (cheap) zif adapter sockets, but they didn't work out for me - not enough space and they don't seat in a socket, they seem to be meant to be soldered to a board, not used in a socket.
Sorry, I do not know anything about that.
I haven't had much luck in finding options for recovery. Ideally I'd like something like the dual switched bios in the old wiki but toggle-able electronically ie. gpio pin from spare router w/ Openwrt. That sounds like a lot of work though and I never managed to find much online as examples.
Yes, it probably depends on the board. I just remember Alexandru Gagniuc’ VultureProg [2]. Kind regards, Paul
[1]: https://review.coreboot.org/c/coreboot/+/40815/ (whole series)[2]: https://blogs.coreboot.org/blog/2013/07/25/vultureprog-equipped-for-galactic...
The LTO patches seem to both compile and work/boot for me on the p2b. I built it both on a debian sid x86_64 system and on the gentoo i686 setup I currently have for the p2b, both with the coreboot crossgcc-i386 toolchain. It looks like it uses the system linker though (or something similiar, I don't remember exactly), at least according to the executable path it shows in the build log. I'm not sure if that's actually what's desired or if I'm just misinterpreting something. It still looks like it needs more test reports yet, though I guess I'm not helping either by not commenting on gerrit. Branden
Hi Branden, list, On Tue, Jun 1, 2021 at 2:10 AM Branden Waldner <scruffy99@gmail.com> wrote:
The LTO patches seem to both compile and work/boot for me on the p2b.
I built it both on a debian sid x86_64 system and on the gentoo i686 setup I currently have for the p2b, both with the coreboot crossgcc-i386 toolchain.
That's great to hear. I hope you didn't need to build crossgcc-i386 on the P2B, though! :P
It looks like it uses the system linker though (or something similiar, I don't remember exactly), at least according to the executable path it shows in the build log. I'm not sure if that's actually what's desired or if I'm just misinterpreting something.
It might be intentional, but it's not desired: using the system toolchain to build coreboot will wreak havoc when cross-compiling.
It still looks like it needs more test reports yet, though I guess I'm not helping either by not commenting on gerrit.
Yes, it needs more test reports. It would be great if you could comment on the Gerrit change, so as to keep all test reports in one place.
Branden
Best regards, Angel
On 6/1/21, Angel Pons <th3fanbus@gmail.com> wrote:
Hi Branden, list,
On Tue, Jun 1, 2021 at 2:10 AM Branden Waldner <scruffy99@gmail.com> wrote:
The LTO patches seem to both compile and work/boot for me on the p2b.
I built it both on a debian sid x86_64 system and on the gentoo i686 setup I currently have for the p2b, both with the coreboot crossgcc-i386 toolchain.
That's great to hear. I hope you didn't need to build crossgcc-i386 on the P2B, though! :P
Well, it's got a gentoo install that has to build it's own updates, including the system compiler, as well as crossgcc-i386. I have to leave it to run for quite a while to do updates or build a new first of crossgcc-i386 on it. It's some pretty tough hardware though, it manages to handle it just fine, even though it is _really_ old for computer hardware at this point. It would probably be a lot faster if I could get a better cpu (w/ proper voltage handling) and the proper ram for it. I do have an ssd attached via a pci sata adapter (which is a bottleneck), but didn't really notice much of an improvement. I guess some people would use (like?) a system like it for retro gaming/computing, but I've never really found a use for it besides testing coreboot on it.
It looks like it uses the system linker though (or something similiar, I don't remember exactly), at least according to the executable path it shows in the build log. I'm not sure if that's actually what's desired or if I'm just misinterpreting something.
It might be intentional, but it's not desired: using the system toolchain to build coreboot will wreak havoc when cross-compiling.
Thankfully, I misunderstood what I was seeing in the logs, it was just while it was building tools that it was using the system toolchain. But, it was using LTO settings for them, which I wasn't expecting. I was assuming it would only use them for actually building the rom, not the utils, but I guess I don't see why not.
It still looks like it needs more test reports yet, though I guess I'm not helping either by not commenting on gerrit.
Yes, it needs more test reports. It would be great if you could comment on the Gerrit change, so as to keep all test reports in one place.
I'll try to get around to commenting on the Gerrit change set yet. Branden
Branden Waldner wrote:
I haven't had much luck in finding options for recovery. Ideally I'd like something like the dual switched bios in the old wiki but toggle-able electronically ie. gpio pin from spare router w/ Openwrt.
That's the product BIOS Savior RD1 from Taiwanese IOSS, switched by a jumper which could be replaced by e.g. a 2N7000 FET driven by a GPIO. https://www.coreboot.org/Developer_Manual/Tools#BIOS_Savior https://www.overclockers.com/bios-savior/ There were a few different versions, IIRC one being for parallel 5V. They seem no longer available, but you could add a watch on ebay or such. VultureProg was mentioned - even a DIY emulator would be fairly straightforward; that's a nice microcontroller project. Where are you located? Branden Waldner wrote:
That's great to hear. I hope you didn't need to build crossgcc-i386 on the P2B, though! :P
Well, it's got a gentoo install that has to build it's own updates, including the system compiler, as well as crossgcc-i386. .. It would probably be a lot faster if I could get a better cpu
You can use Gentoo releng's catalyst tool to build an i686 stage4 on any x86_64 build machine in half an hour or so, you'll just need to use a profile with i686 (17.0 should work) and possibly an older snapshot. If you're interested in trying that I could help with a spec file, catalyst isn't very well documented. //Peter
I haven't had much luck in finding options for recovery. Ideally I'd like something like the dual switched bios in the old wiki but toggle-able electronically ie. gpio pin from spare router w/ Openwrt.
That's the product BIOS Savior RD1 from Taiwanese IOSS, switched by a jumper which could be replaced by e.g. a 2N7000 FET driven by a GPIO.
https://www.coreboot.org/Developer_Manual/Tools#BIOS_Savior https://www.overclockers.com/bios-savior/
There were a few different versions, IIRC one being for parallel 5V.
They seem no longer available, but you could add a watch on ebay or such.
I was thinking specifically of the "dual flash 'pie'" on that page, though really anything would be nice, even just the dip32 risers would probably come in handy.
VultureProg was mentioned - even a DIY emulator would be fairly straightforward; that's a nice microcontroller project.
That seems a bit overkill, but then again flash chips seem to be more expensive then microcontrollers these days. I don't think I'm up to working on something like that right now though.
Where are you located?
I'm in southern Manitoba, Canada. I had been interested in checking out the hackerspace (skullspace) in Winnipeg sometime and seeing if anybody could help me with out with anything but never got around to it. It isn't really local to me though (~2hr drive), and isn't really an option right now for obvious reasons.
That's great to hear. I hope you didn't need to build crossgcc-i386 on the P2B, though! :P
Well, it's got a gentoo install that has to build it's own updates, including the system compiler, as well as crossgcc-i386. .. It would probably be a lot faster if I could get a better cpu
You can use Gentoo releng's catalyst tool to build an i686 stage4 on any x86_64 build machine in half an hour or so, you'll just need to use a profile with i686 (17.0 should work) and possibly an older snapshot.
If you're interested in trying that I could help with a spec file, catalyst isn't very well documented.
I'm not sure that catalyst is really what I want, though it did occur to me now that you mentioned that I could probably use it for a different project. It would be nice if you could just have portage/emerge on the client system request the build server to just make and send binary packages it wants to update - either everything or just whatever has a history of taking more then a certain amount of time on the client - even if it needed to cross compile and/or use qemu. I've seen at least one project that attempted this, but it was abandoned. Even on binary distros it's not that clear how autobuilding/crossbuilding can be done locally with minimal effort. So far I've gotten by just by leaving it running to finish whatever it is working on,.
//Peter
Hopefully that didn't end up getting too off topic. PS. I hope the quoting turns out alright, I really need to get a proper email client setup yet. I had to do it all manually, since it wouldn't pull from the digest properly for some reason. Branden
Hi Branden,
VultureProg was mentioned - even a DIY emulator would be fairly straightforward; that's a nice microcontroller project.
That seems a bit overkill, but then again flash chips seem to be more expensive then microcontrollers these days. I don't think I'm up to working on something like that right now though. Not sure if that might be what you're looking for, but I have successfully used a memSIM2 emulator on a similarly old platform. It's basically an SRAM, some level shifters and a microcontroller to program the SRAM via USB. There's some open source software that can talk to the device; never tested the vendor software. Beware though that you must make sure that there are no +12V on the two pins that might be used for programming voltage; if +12V is present on the socket on the mainboard and you plug the emulator in there, it'll fry the emulator. I ended up plugging a socket with those two pins removed between the socket on the mainboard and the emulator.
Regards, Felix
Felix Held wrote:
Not sure if that might be what you're looking for, but I have successfully used a memSIM2 emulator on a similarly old platform.
Nod, that'll work, even though the implementation is truly gruesome... The price is fair.
It's basically an SRAM, some level shifters
So actually no opto-isolation as the advertising claims?
I ended up plugging a socket with those two pins removed between the socket on the mainboard and the emulator.
Great idea! //Peter
Hi Peter,
So actually no opto-isolation as the advertising claims?
I think there was some galvanic isolation between the USB-serial chip and the microcontroller that connects to the rest of the circuitry. Since I took that device apart maybe 2 years ago, I don't remember the details and I don't have it any more, so I can't just re-check. Regards, Felix
Hi Branden, Branden Waldner wrote:
To: coreboot <coreboot@coreboot.org> Cc: Paul Menzel <pmenzel@molgen.mpg.de>, Angel Pons <th3fanbus@gmail.com>, Peter Stuge <peter@stuge.se> Subject: Re: link time optimization testing Date: Sun, 6 Jun 2021 23:07:37 -0500
I haven't had much luck in finding options for recovery. Ideally I'd like something like the dual switched bios in the old wiki but toggle-able electronically ie. gpio pin from spare router w/ Openwrt.
That's the product BIOS Savior RD1 from Taiwanese IOSS, switched by a jumper which could be replaced by e.g. a 2N7000 FET driven by a GPIO.
https://www.coreboot.org/Developer_Manual/Tools#BIOS_Savior https://www.overclockers.com/bios-savior/
There were a few different versions, IIRC one being for parallel 5V.
They seem no longer available, but you could add a watch on ebay or such.
I was thinking specifically of the "dual flash 'pie'" on that page,
Ah like this: https://www.coreboot.org/Developer_Manual/Tools/Dual_Flash Yes, that's a nice solution, if basic.
though really anything would be nice, even just the dip32 risers would probably come in handy.
A couple of "precision" style DIP32-sockets might do that job? https://www.digikey.ca/en/products/detail/mill-max-manufacturing-corp/110-44...
VultureProg was mentioned - even a DIY emulator would be fairly straightforward; that's a nice microcontroller project.
That seems a bit overkill, but then again flash chips seem to be more expensive then microcontrollers these days. I don't think I'm up to working on something like that right now though.
What capabilities do you have available? Any soldering equipment at all or not under current circumstances (hackerspace mention)?
Where are you located?
I'm in southern Manitoba, Canada.
Okay, so not Europe, but maybe I could send you something.
I had been interested in checking out the hackerspace (skullspace) in Winnipeg sometime and seeing if anybody could help me with out with anything but never got around to it. It isn't really local to me though (~2hr drive), and isn't really an option right now for obvious reasons.
It's a great idea, I'm sure they would be able to help, but 2hr is not so great and yeah not feasible at the moment anyway.
That's great to hear. I hope you didn't need to build crossgcc-i386 on the P2B, though! :P
Well, it's got a gentoo install that has to build it's own updates, including the system compiler, as well as crossgcc-i386. .. It would probably be a lot faster if I could get a better cpu
You can use Gentoo releng's catalyst tool to build an i686 stage4 on any x86_64 build machine in half an hour or so, you'll just need to use a profile with i686 (17.0 should work) and possibly an older snapshot.
If you're interested in trying that I could help with a spec file, catalyst isn't very well documented.
I'm not sure that catalyst is really what I want, though it did occur to me now that you mentioned that I could probably use it for a different project.
It would be nice if you could just have portage/emerge on the client system request the build server to just make and send binary packages it wants to update - either everything or just whatever has a history of taking more then a certain amount of time on the client - even if it needed to cross compile and/or use qemu. I've seen at least one project that attempted this, but it was abandoned.
There's no way for emerge on the client to trigger catalyst on the build server, but the second half works out of the box; catalyst always creates binary packages, which are used by the client emerge by setting PORTAGE_BINHOST in make.conf. So you have to trigger the build some other way (manually, or with other automation) but then have binary packages for easy installation on the client.
So far I've gotten by just by leaving it running to finish whatever it is working on,.
It works well - but takes a long time. :)
PS. I hope the quoting turns out alright, I really need to get a proper email client setup yet. I had to do it all manually, since it wouldn't pull from the digest properly for some reason.
Ouch - yes the digest is not very easy to use - it also has a different message ID than the original posts, so not only is quoting a hassle (yours was fine though!) but the digests break threading too. I completely understand if you don't want lots of individual mails though. Kind regards //Peter
Hi Branden,
VultureProg was mentioned - even a DIY emulator would be fairly straightforward; that's a nice microcontroller project.
That seems a bit overkill, but then again flash chips seem to be more expensive then microcontrollers these days. I don't think I'm up to working on something like that right now though.
Not sure if that might be what you're looking for, but I have successfully used a memSIM2 emulator on a similarly old platform. It's basically an SRAM, some level shifters and a microcontroller to program the SRAM via USB. There's some open source software that can talk to the device; never tested the vendor software. Beware though that you must make sure that there are no +12V on the two pins that might be used for programming voltage; if +12V is present on the socket on the mainboard and you plug the emulator in there, it'll fry the emulator. I ended up plugging a socket with those two pins removed between the socket on the mainboard and the emulator.
Regards, Felix
While it looks like one of those emulators is available for surprisingly cheap compared to most (parallel) flash emulators, it is still quite a bit to spend on an old system just for messing around. It seems kind of weird that it doesn't have proper isolation for the higher programming voltages commonly found on eeprom, though using a socket with those pins removed doesn't seem like too much work.
Peter Stuge wrote: Hi Branden,
I haven't had much luck in finding options for recovery. Ideally I'd like something like the dual switched bios in the old wiki but toggle-able electronically ie. gpio pin from spare router w/ Openwrt.
That's the product BIOS Savior RD1 from Taiwanese IOSS, switched by a jumper which could be replaced by e.g. a 2N7000 FET driven by a GPIO.
https://www.coreboot.org/Developer_Manual/Tools#BIOS_Savior https://www.overclockers.com/bios-savior/
There were a few different versions, IIRC one being for parallel 5V.
They seem no longer available, but you could add a watch on ebay or such.
I was thinking specifically of the "dual flash 'pie'" on that page,
Ah like this:
https://www.coreboot.org/Developer_Manual/Tools/Dual_Flash
Yes, that's a nice solution, if basic.
though really anything would be nice, even just the dip32 risers would probably come in handy.
A couple of "precision" style DIP32-sockets might do that job?
https://www.digikey.ca/en/products/detail/mill-max-manufacturing-corp/110-44... /947066
I'm thinking that ordering some dip32 and dip32-to-plcc32 sockets might be most cost effective for now. I think I already have some plcc32 parallel chips and I can get order more if I need and they are a lot easier to remove and insert then dip32 chips.
VultureProg was mentioned - even a DIY emulator would be fairly straightforward; that's a nice microcontroller project.
That seems a bit overkill, but then again flash chips seem to be more expensive then microcontrollers these days. I don't think I'm up to working on something like that right now though.
What capabilities do you have available? Any soldering equipment at all or not under current circumstances (hackerspace mention)?
I do have some basic soldering equipment and experience, but not a lot. I was hoping for some recommendations for more/better tools if I visited/joined the hackerspace.
Where are you located?
I'm in southern Manitoba, Canada.
Okay, so not Europe, but maybe I could send you something.
I just have a hard time justifying spending money just messing around with old hardware. Even just finding the correct hardware you want/need can be tricky a lot of the time. I would really appreciate it if you think you have extra/spare hardware that I could use though.
I had been interested in checking out the hackerspace (skullspace) in Winnipeg sometime and seeing if anybody could help me with out with anything but never got around to it. It isn't really local to me though (~2hr drive), and isn't really an option right now for obvious reasons.
It's a great idea, I'm sure they would be able to help, but 2hr is not so great and yeah not feasible at the moment anyway.
I had still been considering messaging them, but I'm not sure that would help at this time.
That's great to hear. I hope you didn't need to build crossgcc-i386 on the P2B, though! :P
Well, it's got a gentoo install that has to build it's own updates, including the system compiler, as well as crossgcc-i386. .. It would probably be a lot faster if I could get a better cpu
You can use Gentoo releng's catalyst tool to build an i686 stage4 on any x86_64 build machine in half an hour or so, you'll just need to use a profile with i686 (17.0 should work) and possibly an older snapshot.
If you're interested in trying that I could help with a spec file, catalyst isn't very well documented.
I'm not sure that catalyst is really what I want, though it did occur to me now that you mentioned that I could probably use it for a different project.
It would be nice if you could just have portage/emerge on the client system request the build server to just make and send binary packages it wants to update - either everything or just whatever has a history of taking more then a certain amount of time on the client - even if it needed to cross compile and/or use qemu. I've seen at least one project that attempted this, but it was abandoned.
There's no way for emerge on the client to trigger catalyst on the build server, but the second half works out of the box; catalyst always creates binary packages, which are used by the client emerge by setting PORTAGE_BINHOST in make.conf.
So you have to trigger the build some other way (manually, or with other automation) but then have binary packages for easy installation on the client.
Well, that's the problem, there doesn't seem much in the way of automation for triggering the builds or for installing them, though it would be very nice if there was.
So far I've gotten by just by leaving it running to finish whatever it is working on,.
It works well - but takes a long time. :)
Yep, though it still destroys my raspberry pi v1 b, what a waste getting that thing was. Though I guess part (most?) of the problem is from poor io with the sd card & usb drive I'm using. I'll have to check the open rpi firmware again yet, maybe it's getting closer to usable, then maybe getting better storage could be justified.
Kind regards
//Peter
Thanks for the replies Branden
participants (5)
-
Angel Pons -
Branden Waldner -
Felix Held -
Paul Menzel -
Peter Stuge