coreboot

coreboot@coreboot.org

5 participants
39572 discussions

The road towards LTO: an update and a few question
by Arthur Heymans 28 Feb '24

28 Feb '24

Hi community I picked up the good work done by Jacob Garber to implement link time optimization. The size gains are very substantial, with sometimes up to 15% reduction in binary size! Besides the size benefit it can make us a bit more lazy programmers: for instance we often put static inline functions in headers guarded by preprocessing depending on Kconfig options to not generate code we won't use. With LTO that can be relaxed a bit and the condition to do nothing can come from a separate linked object (at least I presume, I haven't tested). So to do LTO, both with clang and GCC, you use the compiler as a linker frontend, rather than invoke the linker directly. Object files that are optionally generated with the -flto flag to generate LTO optimized binaries. See https://review.coreboot.org/c/coreboot/+/40811 Jacob's patches dealt with GCC. I toyed around with clang. The clang linker frontend only works with LTO if using the GOLD or LLD linker. GCC can use the BFD linker we currently use, so that's an easy transition. Both those linkers, GOLD and LLD are less capable at parsing linker scripts than the BFD linker. Especially for the x86 bootblock, in which we do a lot of stuff, like ID, FIT pointer, ECFW pointer, early 16 bit code, ..., is complicated and those linkers fail on the arithmetics doing all that optimized linking. So my question would be, whether we want to support non BFD linkers and therefore not support all the magic in linker scripts we currently have. At most we are a few bytes less optimal than possible by for instance setting a good hardcoded size and offset of the early 16bit code rather than have the linker script optimize that. As a side note, LTO size gainz are bigger than what would be lost, by a large margin. https://review.coreboot.org/c/coreboot/+/80724/1/src/arch/x86/bootblock.ld is a crude example of how I got lld to be happy with the script. If non BFD linkers are acceptable, how do you propose we deal with it? When not using LTO you could in principle use a different linker of your choosing. Should we just move to lld to make sure CI is happy about linker scripts? Should it be an option, but then we won?t have CI being able to test it except on a few boards put in configs/ ? Maybe have both, but then change the default once LLD is known to work well enough? Sidenote: LLD is faster than BFD but linking is not an expensive step in coreboot anyway. Other more typical linker scripts like the ones you find on ARM and ARM64 platforms work just fine. There are some subtle differences e.g. https://review.coreboot.org/c/coreboot/+/80735 where the heap needs to be declared to not be loaded. There are a few issues though. LLD does not like the RISCV relocation symbols of libgcc.a... I read upstream bugreports about this issue, so maybe that will resolve itself. Same questions with LTO and CI. Should it be an option (IMO yes, as that's what both Linux and u-boot do) and which default settings do we want. For CI reasons LTO is a bit more strict and therefore useful, as the compiler frontend does throw more warnings than the plain linker when linking. What are your thoughts? Are there some caveats about linkers and LTO that are worth knowing, before moving forward? Kind regards Arthur

3 3

Need help from anyone at Meraki/Cisco
by David Hendricks 28 Feb '24

28 Feb '24

Hi folks, As discussed in the Feb. 21 coreboot leadership meeting [1][2], concerns have been raised about coreboot source code releases for certain Meraki switch products. Requests have been made to open-source(a)meraki.com (mailto:open-source@meraki.com) about this with limited success in the past (MX84, MX250), though current requests for MS350 have gone practically unanswered. Since this problem scales with the product line-up, it seems an engineering approach to get code published - preferably upstream - will be a better way to solve it rather than repeated requests or escalation to the SFC. We're looking for anyone from Meraki/Cisco who would like to solve this by getting the code published. Several members of the coreboot community have experience working at (or with) companies in similar situations, and we're willing to help with this process. A few quick ideas mentioned in the recent meeting include a packaging tool to remove unused modules, a repo or branch on coreboot.org to host Meraki changes if they can't be mainlined easily, a license package that can integrate with Meraki's OS installer, etc. It's great that coreboot is used on these products and we believe that the coreboot community and corporate users such as Meraki mutually benefit when everyone's rights are respected. We strongly prefer an engineering approach to compliance with the GPLv2, but will look to other options if progress can't be made. If anyone at Meraki/Cisco happens to be reading this, feel free to contact me privately. [1] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… (https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…) [2] https://www.mail-archive.com/coreboot@coreboot.org/msg58333.html (https://www.mail-archive.com/coreboot@coreboot.org/msg58333.html)

1 0

Are we running libpayload unit tests in the CI?
by Julius Werner 28 Feb '24

28 Feb '24

Hi, We've had unit test support in libpayload for over two years now, but I just noticed that it doesn't look like we're actually running them in the CI? E.g. if I look through a test run like this https://qa.coreboot.org/job/coreboot-gerrit/252761/testReport/(root)/ I can't find them anywhere (most of them have confusingly similar names with coreboot unit tests, but "fmap_locate_area-test" is a unique one). Is that intended or an oversight? Would it be easy to fix? (I'm not super familiar with how the tests are integrated into Jenkins, but the libpayload framework is pretty much a direct copy of the coreboot framework, so if we can run the coreboot ones hopefully it should be easy to run the libpayload ones as well?)

1 0

CHIP_NAME history
by ron minnich 26 Feb '24

26 Feb '24

I notice in bfb11bec3b3fec638adf864a9b9b2cff6671fed8 that CHIP_NAME is gone. I am glad to see it go, but I figured a quick note on history would help. Back in the day, we had coreboot on systems with as little as 256 KiB of memory. That was hard. One of the build options was to have CHIP_NAME result in "", which saved the length of the string + 4 bytes (the pointer). This was, on occasion, the difference between fitting an image or overflowing. It mattered. So the comment: " It was decided to remove this macro altogether, as it does not do anything special and incurs a maintenance burden." is accurate now, since CHIP_NAME always returns the string. But in the era in which CHIP_NAME was created, this comment is not correct.

1 0

Introducing OSFF ByteTalks - Online Webinars about OSF
by Christian Walter 26 Feb '24

26 Feb '24

Hi coreboot community, The Open-Source Firmware Foundation (OSFF) is pleased to announce ByteTalks, a new series of online webinars focused on the open-source firmware community. ByteTalks aims to provide a platform for learning, sharing, and discussing the latest developments in open-source firmware. Each session features talks by experienced professionals, practical tutorials, and a chance for participants to ask questions and engage with the speakers. Whether you're deeply involved in firmware development or just interested in learning more about the field, ByteTalks offers valuable insights and connections to help you grow. Join us to explore the evolving world of open-source firmware together. Announcing OSFF ByteTalks Vol. 1: “*FSP Customization - Remove non-mandatory components in the Intel FSP*” In the realm of open-source firmware, creating a custom Firmware Support Package (FSP) binary is a pivotal step for developers aiming to enhance hardware compatibility and performance. The process involves understanding the hardware's initialization requirements, integrating coreboot or similar open-source firmware solutions, and customizing the FSP to meet specific system needs. Our guests Subrata and Vincent will talk about the process on customizing the Intel FSP and removing non-mandatory components. For more information, check out the event page here: https://osfw.foundation/events/bytetalks-vol.-1/ In case you have any questions, feel free to reach out to me. In case you are also interested in joining the ByteTalks series as a speaker, feel free to reach out to me as well :) Best, Chris -- *Christian Walter* Open-Source Firmware Foundation Email: christian.walter(a)osfw.foundation

1 0

[coreboot - Bug #527] (New) Can't compile coreboot on Arch Linux
by naixin Lv 24 Feb '24

24 Feb '24

Issue #527 has been reported by naixin Lv. ---------------------------------------- Bug #527: Can't compile coreboot on Arch Linux https://ticket.coreboot.org/issues/527 * Author: naixin Lv * Status: New * Priority: Normal * Assignee: naixin Lv * Category: build system * Target version: none * Start date: 2024-02-23 * Affected versions: master * Needs backport to: none * Affected hardware: GIGABYTE GA-H61M-DS2 * Affected OS: none ---------------------------------------- I want to compile coreboot for my Gigabyte GA-H61M-DS2 mainboard, but I only found a short guide for this board at this site: https://www.iot-tech.dev/full.php?ar=166 After downloaded the coreboot git repository, It gave me this error: ``` shell /home/zhongli/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd: build/romstage/console/vtxprintf.o: in function `number': /home/zhongli/coreboot/src/console/vtxprintf.c:63:(.text.number+0x12b): undefined reference to `__udivmoddi4' /home/zhongli/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd: build/romstage/lib/gcc.o: in function `__wrap___divdi3': /home/zhongli/coreboot/src/lib/gcc.c:19:(.text.__wrap___divdi3+0x1): undefined reference to `__divdi3' /home/zhongli/coreboot/util/crossgcc/xgcc/bin/x86_64-elf-ld.bfd: build/romstage/lib/gcc.o: in function `__wrap___udivdi3': /home/zhongli/coreboot/src/lib/gcc.c:20:(.text.__wrap___udivdi3+0x1): undefined reference to `__udivdi3' make: *** [src/arch/x86/Makefile.mk:191: build/cbfs/fallback/romstage.debug] Error 1 ``` And I'll put my config file on here. Any help ? ---Files-------------------------------- defconfig (726 Bytes) ifd_shrinked.bin (4 KB) me_shrinked.bin (96 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

3 4

coreboot/linuxbios for oldies insyde?
by meaudron 24 Feb '24

24 Feb '24

hello i have several old laptops here (2010/20) those are running general public/retail "insyde" h2 bios, specially made for grandma (hp, toshiba, vaio, asus..) i'd like to know if it's possible to make working a linuxbios/coreboot image for those. as : a/ is it possible to check if insyde bios could be replaced by a type of linuxbios? b/ is it possible as flashing it directly on the internal programmer?c/ does linuxbios is able to manage a windosw boot, as some laptops have dual win/nux boot (some with bsd on it too)

1 0

I can't build crossgcc
by Keith Hui 23 Feb '24

23 Feb '24

Hi guys, I was unable to build crossgcc. The important tail end of build log is included at the end. I couldn't figure out why. There should be no binutils-2.33.1 anywhere on my system. The build script is pulling in 2.41, and my host binutils is 2.40. Appreciate any help. Thanks Keith ---8<--- make[2]: Entering directory '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS/zlib' make[2]: *** No rule to make target '../../binutils-2.33.1/zlib/adler32.c', needed by 'libz_a-adler32.o'. Stop. make[2]: Leaving directory '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS/zlib' make[1]: *** [Makefile:10810: all-zlib] Error 2 make[1]: Leaving directory '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS' make: *** [Makefile:1004: all] Error 2 make[1]: Entering directory '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS' /bin/sh ../binutils-2.41/mkinstalldirs /usr/src/coreboot/util/crossgcc/xgcc /usr/src/coreboot/util/crossgcc/xgcc /bin/sh: line 4: cd: ./libsframe: No such file or directory make[1]: *** [Makefile:12900: install-libsframe] Error 1 make[1]: Leaving directory '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS' make: *** [Makefile:2580: install] Error 2

2 2

2024-02-21 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 22 Feb '24

22 Feb '24

# 2024-02-21 - coreboot Leadership Meeting Minutes ## Attendees Martin Roth, Felix Held, Felix Singer, Jay Talbott, Julius Werner, Marcus Andrews, Matt DeVillier, Maximilian Brune, Nicholas Chin, Nico Huber, Stefan Reinauer, Patrick Georgi, Paul Menzel, Werner Zeh, Mina Asante, Daniel Maslowski, David Hendricks, Jules Irenge, Lean Sheng Tan, Marshall Dawson, Kharthik Ramasubramanian. ## Open Action Items * 2024-01-10 * Open Werner: Push patch based on https://ticket.coreboot.org/issues/522 * Nico: https://review.coreboot.org/q/topic:enforce_region_api * Open Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### We’ve switched to BigBlueButton for this meeting * https://bbb.sfconservancy.org/b/mar-sfn-e22-axi * For phone access, call +1-718-247-9666, then enter 89421 as the conference PIN number. * It looks like there’s only a USA phone number. * I found some apps, but they seem to be to run the meeting, not to join it. * See the coreboot calendar for times and more information. * There are a number of reasons for this change - I’ve listed 2 of the major reasons below. * We’d like to use open source projects in our infrastructure when we can, and not rely on proprietary services. * We’ve been using a google chat meeting set up by a google employee for all this time. This allows us to have more than the default number of users in a meeting, but has the downside that a google employee must be present on the call to allow people into the meeting. We’ve had several meetings recently where people were not being allowed in simply because no google employees had joined. We want to get rid of that issue. * [Felixh] Audio is much better than the last time we tried BBB. * Paul is a fan of BBB over google chat. * Julius usually does the meeting “on the go” and the BBB doesn’t work well for that. * Despite some small issues due to needing to learn about the new platform, the meeting went smoothly. BBB seems to work well enough to keep. ### [FelixH] Look at the type that we should be using for readXX * Currently we’ve been using void*, but it’s been argued that using an uintptr_t would be preferable. * Should we use ‘_Generic’? * We’d like to have just a single type. * Turned out to be very tedious to gather statistics. * Most values come from #defines and are integer types to begin with. * Things getting cast as (void *)(uintptr_t)var to use the current functions. * If there weren’t Arm code that was using pointers in structures, the recommendation would be to switch to uintptr_t, but with those, it would take a lot of reworking. * Can we just continue as we have been and cast everything to void * before reading and writing? Can we use macros to do this? * Objection to using an inline function that takes a uintptr_t and converts it to a void * - this can lead to bad practices? * FelixH - Opposed to getting rid of the uintptr_t functions * Werner - what is the most used type? Uintptr or void *? * Felix everything but arm uses more uintptr - arm uses void *. * It sounds like there are reasons for both functions. * Both functions go through the void* function, so it’s not two completely separate functions. * Shouldn’t have any real impact. * Felix will write up a document and present at least a few examples. **Decision: Due to the above, there are no objections to keeping both sets of functions at this point.** * David: But please let's avoid excessive casting or conversions. Go to EDK2 sources and grep for UINT and VOID in the same line to get a sense of what we should avoid… * Some data (added after the meeting): * It was a bit difficult and tedious manual process to get at least some statistics, since in some of the cases it wasn’t completely clear if some MMIO address should be counted as originally integer or originally pointer; if in doubt, I also looked at the call sites of functions to see which type the parameter that was used had originally. There are also quite a few helper macros and inline functions that wrap the different read/write functions making it even more difficult to get some good quantitative data, so this is mostly qualitative. * [read,write][8,16,32,64]p use integer MMIO addresses in all but 2 call sites * A lot of MMIO addresses are from defines and uintptr_t * Also some uint32_t, uint64_t or resource_t * The native RAM init for different Intel SoCs heavily uses read/write functions taking the MMIO addresses as uintptr_t * [read,write][8,16,32,64] use sometimes integer and sometimes pointer as source of the MMIO address that gets passed in as pointer * ‘&struct->element’ is a common construct to get the MMIO addresses in the Cavium, Mediatek, Nvidia, Qualcomm, Rockchip, Samsung, TI, and Sifive code; also used in the Designware I2C driver. Mediatek however also uses the [read,write][8,16,32,64]p functions in some places. * ‘&array[offset]’ is also a construct used in some places * res2mmio casts the resource_t value with (void *)(uintptr_t) so changing that to uintptr_t would be a bit more native * Buffer returned by rdev_readat is a pointer * Some ARM SoCs have the cast to a pointer in the defines * Other defines are mainly integers that get cast to pointers somewhere in the code * x86 SoC code uses a mixture of both integer and pointer MMIO functions, but the original MMIO addresses are in most cases integers. ### [Nico] Revoking Gerrit privileges as punishment. * I would like to discuss two matters about this. Not sure about the order. * My own case: I was removed from the core developers and reviewers groups 20 months ago. Without any charge nor chance to defend myself. There was Stefan's sentence, a discrediting rant about me with accusations that fit me not more than many other people, and an offer to reduce the sentence to a month if I were willing to come to the table. Which didn't make sense because I reached out to people long before Stefan's mail and it took Stefan, not me, over three months "to come to the table". And then he still couldn't tell me what I did worse than others. I asked again, Werner this time, what my charge is in 2023, again without results. And now I'm asking again. How can we make things better when we can't even say what was wrong? * [Martin] These issues are not discussed in a public forum where everyone with a pitchfork can get involved. That’s not useful. If you feel that the issues which led to this action being taken have changed, please email all the members of the leadership. Matt, Werner, and David. * Should we use Gerrit privileges as punishment at all? If so, shouldn't we have rules about it? * We will add this to the code of conduct page: ``` As a part of running the project, coreboot leadership has the right to revoke privileges as they see fit. This is not done lightly. Over the history of the coreboot project, there have been only a handful of times where an action needed to be taken. Discussions about these actions are not done publicly, for obvious reasons. If someone believes that the circumstances that led to an action have changed, please send an email to all the members of the leadership team for discussion. ``` I will note that this text is already there: ``` If a community member engages in unacceptable behavior, the community organizers may take any action they deem appropriate, up to and including a temporary ban or permanent expulsion from the community without warning (and without refund in the case of a paid event). ``` * [Code of Conduct](https://doc.coreboot.org/community/code_of_conduct.html). * Doesn't it hurt the project more when it loses a reviewer? (who can still get their own patches merged anyway) * [Martin] I’d say yes, and that’s something that the leadership group has to weigh when they decide to take an action against an individual. * [David] Yes, it does hurt the project when it loses a reviewer (or any contributor, for that matter). That's why it's important to deal with "toxic developers" effectively - to prevent others from leaving the project. No one developer is worth several others who will refuse to work with them. * Should we maybe do the opposite? don't merge their patches unless they do review? * [Martin] When the issue is something other than the quality of a person’s code, it doesn’t make sense to punish them by refusing to allow their patches to be merged. As many people in the community have jobs where they’re required to push code to coreboot, that could be the equivalent to getting them fired, which seems unfair. * If we want to use such punishment, should we apply it to other privileges as well? e.g. administrators, leadership members (IMO very important for trust inside the community) * [Martin] If two members of the leadership voted to take action against a third member, that’s completely allowed. The leadership team can take action as needed. I’ll note that I myself had submit rights taken away for a year. Yes, I’m one of the handful of cases mentioned. * David - We're in between two extremes - instant banning when someone is determined to have violated the code of conduct, and anything goes with little or no enforcement of rules. Neither are great, we try to use our discretion to smooth out issues in the long-run without being too heavy handed. * ...but is the process too opaque and complicated? We aren't lawyers and don't want a complicated "legal" system for coreboot. Rules need to be simple, universally understandable, and enforceable. Maybe we need to enforce stiff penalties, at least for a temporary term, before returning things to normal. * Paul - Make sure we have good communication. The “sentence” should be limited, and communicated to the person. * Stefan: What’s a reasonable length of time? There are 2 main situations that we’ve dealt with in the past. * 1) something happens and people get a slap on the wrist. * 2) There’s an ongoing issue that happens over and over. * One person who had an action taken against him refused to take responsibility and could not change, even after repeated talks. * Nico: Make sure that everyone involved is in the discussion. ### [Martin] Remove ChromeEC as a submodule - reimplement like a payload * The ChromeEC can currently be built (for some platforms) as a part of the coreboot build. It’s being downloaded as a submodule right now, but this creates a number of issues. With the change to Zephyr, the build process and requirements have changed. To address this, I’d like to propose that we drop the ChromeEC as a submodule, which restricts us to a single version of the code which can be used across all mainboards. With an implementation similar to what’s done for the payloads, the ChromeEC can still be pulled down by platforms which want to build it, and each platform can select a different commit if needed. **Decision: Go ahead and remove as a submodule. The new implementation can be reviewed in gerrit.** ### [Martin] Drop Tioga-pass & Skylake-SP? * Marc gave these both +2, so I’m inclined to believe they should be removed, as he was one of the significant contributors, but I’d like to get everyone’s input. “The platform code depends on unreleased binary files and uses incomplete public header files.” * https://review.coreboot.org/c/coreboot/+/80171 * https://review.coreboot.org/c/coreboot/+/80172 Should they be removed immediately as incomplete and unlikely to be finished? * David: Only applies to skylake Xeon-SP * Intel never allowed the release of the FSP. * Servers are much longer lived - no issue with this living on in a branch. * SKX servers are being decommissioned en masse at this point, so it would be nice if someone can find pointers to SysPro and how to get it working. * Jay: Worked on this for a good bit of time for IT Renew - had internal build working. FSP was working. Ran out of funding to complete the project. * Label it so that we could pick it back up if needed. * The framework is useful - we don’t want it to just be killed. * Millions of nodes available, but no interest in coreboot. * Nico: Arthur should be asked - this shares a lot of code with the newer generation of xeon-sp. This should probably be kept if possible. * FelixH: Shouldn’t just throw it out - shouldn’t cause too much of a burden. * FelixS: Will intel release future FSPs for these platforms? * David: They should be available somewhere (other than skylake). * Skylake-SP: Not officially supported, but available from SysPro with some caveats. * Cooper Lake: Not officially supported, but available from OCP Delta Lake firmware images. * Sapphire Rapids / Eagle Stream: FSP is on Github now: https://github.com/intel/FSP/tree/master/EagleStreamFspBinPkg * Granite Rapids: Will be put up on the Github FSP repo eventually. ### [David] Meraki (Cisco) - Escalate compliance issue to SFC * Another year, another potential GPL violation from Meraki. Late 2022/early 2023 we were dealing with a complaint about MX84 and MX250 products (Rangely and Broadwell-DE). Cisco did release the code eventually (https://github.com/halmartin/coreboot-mx84 and https://dl.meraki.net/bootloader-mx250-20230105.tar.bz2), but it took a little over a year from the initial request. This time the request is concerning the MS350. * I sent an e-mail to [open-source(a)meraki.com] in October '23, but aside from what appears to be a canned response (weirdly sent weeks later) there has been no progress. Time to escalate with SFC again. * What can be done to get Meraki into compliance in a friendly way? It's great to have a large vendor using coreboot and the relationship between Meraki and the coreboot community can be mutually beneficial, but only if everyone's rights are respected. * Martin: I’ve got ideas on how to make it easier to release, but I probably need help to get these done. * Licensing: create a license package that can be built into the coreboot image. These can be displayed by the setup engine or in the OS. * Package the specific build. I’ve created a tool - util/scripts/rm_unused_code that removes all of the unused source files from the coreboot tree, then creates a patch to delete those files. I’ve got an update for this patch, but haven’t had time to work on it in a while. * David will send an email to the mailing list asking for anyone from Cisco to help us with this before the lawyers get involved. ### [DanielM] “What is coreboot” draft progress 📝📈 * Met with David and Max last week, ended up with a good bunch of notes (4 pages, thanks a lot both of you!), will tidy them up and then present as the “final draft” next time 🙂 \ ### 24.02 release The release tag was done on Monday the 19th. The announcement will be done on Monday 2024_02_26 Next release is 24.05. * Martin: There’s some confusion about freezes and how the releases are done at this point. We need to document that. A lot has changed since the last time we documented the process. # Next meeting * March 6, 2024. * [Meeting link](https://bbb.sfconservancy.org/b/mar-sfn-e22-axi). * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes [2024-02-21](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1….

1 0

Leadership meeting -- BigBlueButton mobile support
by Julius Werner 21 Feb '24

21 Feb '24

Hi, After we just tried out BigBlueButton for the meeting, I have to say that I found its mobile support unfortunately lacking. It doesn't have an official Android app as far as I can tell, and the only unofficial one I found (https://play.google.com/store/apps/details?id=com.bigbluebuttonmobile) says "this item isn't available in your country" when I try to install it in the US. I can open the website from a mobile browser but then it doesn't have any mobile-specific UI or features (like using the "phone call" speaker instead of the big one), so it's pretty useless for that. I usually need to take part of the meeting on the go, and it seems that the only useable option for that is the POTS phone bridge which is obviously not a great experience (can't raise hands, can't see when other people have hands raised, etc.). I'm not sure for what reasons other people were asking to switch away from Google Meet, but I just wanted to add the data point that at least for my use case, it worked way better.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot