Re: [coreboot] Asus M2N-E: Waiting for 1 CPUS to stop
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2017 03:45 AM, Martin A wrote: > > > Hi there, > > > In my bunch of motherboards, the only one supported by Coreboot is my > old Asus M2N-E with Dual-Core AMD Opteron(tm) Processor 1216 HE and 4x > 2Go Ram (2@667 and 2@800). > > > So I tried to run it with Coreboot an Seabios but nothing happened on > screen and at the end of the boot log: > > Waiting for 1 CPUS to stop > > > And a bit sooner in boot log > > CPU ID 0x8001: 40f33 > CPU is Fam 0Fh rev.F or later. We can use TOM2WB for any memory above 4GB > > Any advice to solve it please ? > Thank you. > Can you post the full boot log please? The modern Opterons occasionally hang at that same location when the debug level is set to SPEW; something you could try is to reduce the debug level to WARNING and see if the board boots. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJZHyQwAAoJEK+E3vEXDOFbylkH/jnSBLmHnRt0wZAusjIBxQX5 578UF/GxZ6kDKtkGbHvwg/+TIABC8X7CEqIG49u1KDhJfQb8+jDyQ4/oEULVWyIB DC0GEyJHOen8JJpKhTksfk5yf+qkiEIUPNCENdmM8pOUXZzryM34Ng30yHEL8nqE v2qHMgWaAjFHC5GuQGIoXk9B7afeQbvFPA8rxOztN/7NJPOf2+xzljetquxk+rRl Kugf8I9carM/Dod2rjX/rzO3QMpl9Wg3Ob/CvqBU0JKONjNxRcJU7UVeaOcRmNr1 neO8hdL5lCw2rRA6cR61HELC9fYNC61HkbmSX0JlcQw2XXCJd8CgTKncXMqDQ0k= =1zxc -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Easier accessibility for coreboot/flashrom wikipedias? What do you think?
First, I agree with the goal of lowering the administrative overhead for write access to the wiki. qma ster wrote: > My proposal is to give the edit rights to all the subscribers of the > coreboot/flashrom mailing lists .. > I strongly believe that all the members of coreboot/flashrom > mailing lists are responsible smart individuals I don't believe that at all. There is no evidence whatsoever to support that all subscribed email addresses actually correspond to individuals. I expect that many list recipients are programs. > Alternatively, the registration could be made completely open, but > with a strong registration/login captcha or maybe even per-edit > captcha to prevent the automatic bots/spammers from ruining the > wiki pages CAPTCHA is not a good tool. It is easy to acquire human solving capacity if you can offer something desirable in exchange. It only stops very low end bots, and unless the challenge is self-hosted it is likely actually training some other bots. I think a more workable and sustainable solution is to enable more people to grant write access. Another project uses an IRC bot for this task, so that a group of trusted users on the IRC channel(s) can grant write access immediately. It works really well. However, it requires some programming to implement. Please volunteer to work on creating this solution if you can. I guess that it's about a week of R //Peter -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] New Defects reported by Coverity Scan for coreboot
Hi,
Please find the latest report on new defect(s) introduced to coreboot found
with Coverity Scan.
6 new defect(s) introduced to coreboot found with Coverity Scan.
5 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent
build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 6 of 6 defect(s)
** CID 1375445: Uninitialized variables (UNINIT)
/src/soc/rockchip/rk3399/mipi.c: 159 in rk_mipi_dsi_phy_init()
*** CID 1375445: Uninitialized variables (UNINIT)
/src/soc/rockchip/rk3399/mipi.c: 159 in rk_mipi_dsi_phy_init()
153 TER_RESISTOR_HIGH | LEVEL_SHIFTERS_ON |
154 SETRD_MAX | POWER_MANAGE |
155 TER_RESISTORS_ON);
156
157 write32(_regs->dsi_phy_rstz, PHY_ENFORCEPLL |
PHY_ENABLECLK |
158 PHY_UNRSTZ | PHY_UNSHUTDOWNZ);
>>> CID 1375445: Uninitialized variables (UNINIT)
>>> Using uninitialized value "ret".
159 return ret;
160 }
161
162 static inline int mipi_dsi_pixel_format_to_bpp(enum
mipi_dsi_pixel_format fmt)
163 {
164 switch (fmt) {
** CID 1375444: Integer handling issues (REVERSE_NEGATIVE)
/src/soc/intel/common/block/i2c/i2c.c: 101 in lpss_i2c_dev_init()
*** CID 1375444: Integer handling issues (REVERSE_NEGATIVE)
/src/soc/intel/common/block/i2c/i2c.c: 101 in lpss_i2c_dev_init()
95 {
96 const struct lpss_i2c_bus_config *config;
97 int bus = lpss_i2c_dev_to_bus(dev);
98
99 config = i2c_get_soc_cfg(bus, dev);
100
>>> CID 1375444: Integer handling issues (REVERSE_NEGATIVE)
>>> You might be using variable "bus" before verifying that it is >= 0.
101 if (!config || bus < 0)
102 return;
103
104 lpss_i2c_init(bus, config);
105 }
106
** CID 1375443: Integer handling issues (OVERFLOW_BEFORE_WIDEN)
/src/soc/rockchip/rk3399/mipi.c: 194 in rk_mipi_dsi_get_lane_bps()
*** CID 1375443: Integer handling issues (OVERFLOW_BEFORE_WIDEN)
/src/soc/rockchip/rk3399/mipi.c: 194 in rk_mipi_dsi_get_lane_bps()
188 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
189 if (bpp < 0) {
190 printk(BIOS_DEBUG, "failed to get bpp for pixel format
%d\n",
191dsi->format);
192 return bpp;
193 }
>>> CID 1375443: Integer handling issues (OVERFLOW_BEFORE_WIDEN)
>>> Potentially overflowing expression "edid->mode.pixel_clock * 1000U"
>>> with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit
>>> arithmetic, and then used in a context that expects an expression of type
>>> "u64" (64 bits, unsigned).
194 pclk = edid->mode.pixel_clock * MSECS_PER_SEC;
195 /* take 1 / 0.8, since mbps must bigger than bandwidth of RGB */
196 target_bps = pclk / dsi->lanes * bpp / 8 * 10;
197 if (target_bps >= max_bps) {
198 printk(BIOS_DEBUG, "DPHY clock frequency is out of
range\n");
199 return -1;
** CID 1375442: Control flow issues (NO_EFFECT)
/src/soc/intel/apollolake/i2c.c: 47 in i2c_soc_bus_to_devfn()
*** CID 1375442: Control flow issues (NO_EFFECT)
/src/soc/intel/apollolake/i2c.c: 47 in i2c_soc_bus_to_devfn()
41 return PRERAM_I2C_BASE_ADDRESS(bus);
42 }
43
44 /* Convert I2C bus number to PCI device and function */
45 int i2c_soc_bus_to_devfn(unsigned int bus)
46 {
>>> CID 1375442: Control flow issues (NO_EFFECT)
>>> This greater-than-or-equal-to-zero comparison of an unsigned value is
>>> always true. "bus >= 0U".
47 if (bus >= 0 && bus <= 3)
48 return PCI_DEVFN(PCH_DEV_SLOT_SIO1, bus);
49 else if (bus >= 4 && bus <= 7)
50 return PCI_DEVFN(PCH_DEV_SLOT_SIO2, (bus - 4));
51 else
52 return -1;
** CID 1375441: Integer handling issues (NEGATIVE_RETURNS)
/src/soc/intel/common/block/i2c/i2c.c: 122 in lpss_i2c_acpi_fill_ssdt()
*** CID 1375441: Integer handling issues (NEGATIVE_RETURNS)
/src/soc/intel/common/block/i2c/i2c.c: 122 in lpss_i2c_acpi_fill_ssdt()
116 enum i2c_speed speeds[LPSS_I2C_SPEED_CONFIG_COUNT] = {
117 I2C_SPEED_STANDARD,
118 I2C_SPEED_FAST,
119 I2C_SPEED_FAST_PLUS,
[coreboot] Asus M2N-E: Waiting for 1 CPUS to stop
Hi there, In my bunch of motherboards, the only one supported by Coreboot is my old Asus M2N-E with Dual-Core AMD Opteron(tm) Processor 1216 HE and 4x 2Go Ram (2@667 and 2@800). So I tried to run it with Coreboot an Seabios but nothing happened on screen and at the end of the boot log: Waiting for 1 CPUS to stop And a bit sooner in boot log CPU ID 0x8001: 40f33 CPU is Fam 0Fh rev.F or later. We can use TOM2WB for any memory above 4GB Any advice to solve it please ? Thank you. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Easier accessibility for coreboot/flashrom wikipedias? What do you think?
Dear coreboot/flashrom mailing list members, As you may have noticed it is not that easy or straightforward to gain the edit rights for coreboot/flashrom wikipedias so the people are mass migrating to the unofficial wikis. For example: recently Zoran Stojsavljevic had to bring his Coreboot/VBT article to Jimmy Wales wikipedia instead of coreboot wikipedia, Mike Banon had to put his EC KB9012 chip flashing article to DangerousPrototypes wikipedia instead of flashrom wikipedia, and I could provide many other similar examples if needed Currently, to get the edit rights for coreboot/flashrom wikipedias you have to personally contact the wikipedias administration, who are the highly active open source developers with a lot of things to do and may simply forget to review your request - and you have to provide a good enough detailed explanation of what exactly you are going to write or edit, despite that your plans might change and suddenly you would like to improve another article, write your own, or maybe even want to improve the many other random articles: doing small changes like fixing the typos / replacing the broken links / updating the clearly outdated information / other fixes that are minor by nature but still are majorly improving the wikipedias quality I believe that the current administrative barriers are too high: to gain the edit rights you should not be required to go through what seems to be like a job interview, especially because this is not like a job offer and your work at these wikipedias will be unpaid My proposal is to give the edit rights to all the subscribers of the coreboot/flashrom mailing lists, or at least to all those who have been the subscribers for at least a day / a week / or a month. Could see only the positive outcome from this action, because I strongly believe that all the members of coreboot/flashrom mailing lists are responsible smart individuals and their wiki contributions will be of high quality. Alternatively, the registration could be made completely open, but with a strong registration/login captcha or maybe even per-edit captcha to prevent the automatic bots/spammers from ruining the wiki pages Please share your opinions about this proposal. It is interesting to hear your thoughts, and maybe they could influence the coreboot/flashrom projects future Best regards, qmastery -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
