Re: [coreboot] separate mailling list for gerrit mails?
Hi all, Although I filter them to separate folder, it would be good to split them to make archives somewhat less intermixed. Or as Kevin suggests leave only mail that something has been merged. Thanks, Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] separate mailling list for gerrit mails?
although i can split the gerrit address by myself, i would still like coreboot can help to separate it. Best wishes QingPei Wang Phone: 86+018930528086 On Mon, Mar 12, 2012 at 3:24 PM, Rudolf Marek r.ma...@assembler.cz wrote: Hi all, Although I filter them to separate folder, it would be good to split them to make archives somewhat less intermixed. Or as Kevin suggests leave only mail that something has been merged. Thanks, Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/**mailman/listinfo/coreboothttp://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] separate mailling list for gerrit mails?
On 10.03.2012 21:04, Patrick Georgi wrote: Hi, this came up on IRC again, but I think the issue requires wider discussion: Several people asked if gerrit mails can be moved to a separate mailing list to reduce the mechanic noise. We're highly flexible there, so we can keep it like it is, reduce the number of mail types, send different types to different lists, ... For me the annoying thing is that gerrit is not fully integrated into the mailing list and vice versa, too. Review done on the gerrit web page is not mirrored to the mailing list and reviews done on the mailing list gerrit will not be aware of. So it would be nice to see the reviews done on the gerrit web page as emails on a mailing list, too. Another point, already mentioned, would be to give those patch set updated emails some more value. When I push an update to git, gerrit already tells me what has changed (i.e., only rebased or subject changed or files, too). It would be nice to at least get this information from the gerrit web site and from the emails, too; interdiff would be a bonus. Non-updates, i.e. unchanged commits of a series, should have no effect at all - no email, no new patch set. It just destroys previous reviews. But I guess this would require some changes to the gerrit code base?! As those proposed changes would even increase the gerrit email traffic I'd love to have those on a separate mailing list. Not because I'm unable to filter my emails but to avoid making new subscribers uncertain about the intend of the mailing list. To much automated traffic might make them skip the lurking phase and just pass on to another project. Developers instead, should clearly subscribe to the gerrit mailing list to get updates about the currently ongoing changes. Mirroring gerrit merge emails to the coreboot mailing list is also a good idea, as newcomers will get an idea of the ongoing development. So, +1 for slit mailing lists. Mathias -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASRock E350M1 video option ROM?
On 11/03/12 05:04, Scott Duplichan wrote: I know of two ways to extract the legacy video option rom: a) Download the image from the manufacture's web site: 1. ftp://174.142.97.10/bios/CPU/E350M1(1.50)ROM.zip 2. Extract the 4MB UEFI image (E350M11.50) 3. Use 7-zip (version 9.21 beta) to decompress. 4. Hex edit this file: E350M1(1.50)ROM\2\CSMCORE\1.raw 5. Find the start of the video option rom. It starts with 55 AA and contains text AMD Fusion Wrestler generic VBIOS 6. The length is the byte after 55 AA (71) * 200h = E200h. 7. Extract E200 bytes starting at 55 AA. b) When the board arrives... 1) Boot MSDOS and start DOS debug 2) At the - prompt, enter these commands: -n vga.bin -rbx -1 -w 3) The option rom is vga.bin in the current directory. Thanks, Scott a) is good. b) is just going to get you 64KB of unintialised data. There is nothing in those instructions to access the video BIOS AFAICT. Andrew -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASRock E350M1 video option ROM?
Regarding ATI cards, (and i assume this board has such card), you can grab the bios from /proc under linux. That worked for R300/R500 radeon video cards, maybe it still works on more recent ones : as root: cd /sys/bus/pci/devices/pci bus id/ echo 1 rom cat rom /tmp/vbios.rom echo 0 rom Keep in mind, i am not sure it's 100% complete ram bios, but that's what xorg ati devs suggested as steps to dump the bios when identifying some bugs with radeon hardware on linux. 2012/3/12 Andrew Goodbody ajg4tadp...@gmail.com On 11/03/12 05:04, Scott Duplichan wrote: I know of two ways to extract the legacy video option rom: a) Download the image from the manufacture's web site: 1. ftp://174.142.97.10/bios/CPU/**E350M1(1.50)ROM.zipftp://174.142.97.10/bios/CPU/E350M1%281.50%29ROM.zip 2. Extract the 4MB UEFI image (E350M11.50) 3. Use 7-zip (version 9.21 beta) to decompress. 4. Hex edit this file: E350M1(1.50)ROM\2\CSMCORE\1.**raw 5. Find the start of the video option rom. It starts with 55 AA and contains text AMD Fusion Wrestler generic VBIOS 6. The length is the byte after 55 AA (71) * 200h = E200h. 7. Extract E200 bytes starting at 55 AA. b) When the board arrives... 1) Boot MSDOS and start DOS debug 2) At the - prompt, enter these commands: -n vga.bin -rbx -1 -w 3) The option rom is vga.bin in the current directory. Thanks, Scott a) is good. b) is just going to get you 64KB of unintialised data. There is nothing in those instructions to access the video BIOS AFAICT. Andrew -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/**mailman/listinfo/coreboothttp://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Trac reminder: list of new ticket(s)
Ticket Owner Status Description #186 ste...@coresystems.de new 3com 3c905tx / gpxe boot problem #185 ste...@coresystems.de new Vtech partial success #184 ste...@coresystems.de new Asus p2b with aty128 fails #183 ste...@coresystems.de new SeaBIOS: test-gcc.sh executed multiple times, also during make clean #182 u...@hermann-uwe.de new superiotool installs man page with +x perms #181 ste...@coresystems.de new Tyan S2885 (and other K8 boards) won't boot with TINY_BOOTBLOCK #180 ste...@coresystems.de new ASRock E350M1 Gigabit Ethernet Problem #178 ste...@coresystems.de new linux kernel hang while boot from SATA SSD on EPIA CN #176 ste...@coresystems.de new inteltool: added PCI_DEVICE_ID_INTEL_X44 0x29e0 #174 ste...@coresystems.de new Unable to boot from qemu-kvm -- seems to be a cbfs problem #168 ste...@coresystems.de new USBDEBUG might slow down coreboot #162 oxygene new Move SYSTEM_TYPE to Kconfig #160 oxygene new Build system: There's no convincing CFLAGS management for util/* #158 w...@gnu.org new buildrom svn error #156 hailfinger new Add Layout File capability to v3 and LAR tool #154 hailfinger new Flashing BIOSes from Fujitsu/Siemens is not supported #150 somebody new AMD DB800 dev board PLL strapping leaves CPU and GLIU in non-optimal clock #147 somebody new Linux kernel halts when scanning the PCI bus below 0:14.4 on RS690 #145 somebody new Fix CMOS handling #143 oxygene new unify intel car for model_6[ef]x #135 ward new Flashrom deletes MAC addresses on Tyan Tomcat n3400B (S2925-E) #129 stepan new etherboot payload does not work with HIGH_TABLES #128 somebody new Improve email user interface for trac #125 somebody new BCM5785 / HT1000 reset functions #111 somebody new Add i18n support for translating strings e.g. for bayou / coreinfo #110 somebody new Allow for per-device subsystem IDs #77 somebody new hang on the "Jumping to coreboot" step on via epia-m with 4-chip 128Mbyte DDR module #76 rminnich new coreboot messages should be accessible in dmesg #18 oxygene new autoprobe apic cluster and application processors on K8 systems #17 stepan new clean up coreboot table handling #16 ollie new I2C driver and mainboard Config.lb #11 yhlu new pirq table automation #5 uwe new Add license header to all source files #2 somebody new Complete tables of supported motherboards -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Asus M2N-E problem
Hello,
as i saw ASUS M2N-E motherboard on the list of supported motherboards,
I decided to give a try to this very interesting project.
I compiled coreboot via crossgcc with very default options, I only choose
the vendor, the board and SeaBIOS as payload.
Everything went fine and I flashed coreboot.rom via flashrom utility.
Also here everything went fine.
Then I did restart, but there was no VGA output.
So I connected my laptop as serial console and got an output.
According to this output coreboot starts, initializes some of the hardware
but in some moment does softreset and this is happening in the infinite loop.
I saved the output which looks like this:
coreboot-4.0-2082-gccf28ba Tue Mar 6 14:42:21 CET 2012 starting...
*sysinfo range: [000cf000,000cf730]
bsp_apicid=0x00
Enabling routing table for node 00 done.
Enabling UP settings
coherent_ht_finalize
done
core0 started:
started ap apicid: * AP 01started
SBLink=00
NC node|link=00
entering optimize_link_incoherent_ht
sysinfo-link_pair_num=0x1
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x75
pos=0x52, unfiltered freq_cap=0x807f
pos=0x52, filtered freq_cap=0x7f
freq_cap1=0x75, freq_cap2=0x7f
dev1 old_freq=0x0, freq=0x6, needs_reset=0x1
dev2 old_freq=0x0, freq=0x6, needs_reset=0x1
width_cap1=0x11, width_cap2=0x11
dev1 input ln_width1=0x4, ln_width2=0x4
dev1 input width=0x1
dev1 output ln_width1=0x4, ln_width2=0x4
dev1 input|output width=0x11
old dev1 input|output width=0x11
dev2 input|output width=0x11
old dev2 input|output width=0x11
after ht_optimize_link for link pair 0, reset_needed=0x1
after optimize_link_read_pointers_chain, reset_needed=0x1
mcp55_num:01
ht reset -
coreboot-4.0-2082-gccf28ba Tue Mar 6 14:42:21 CET 2012 starting...
*sysinfo range: [000cf000,000cf730]
bsp_apicid=0x00
Enabling routing table for node 00 done.
Enabling UP settings
coherent_ht_finalize
done
core0 started:
started ap apicid: * AP 01started
SBLink=00
NC node|link=00
entering optimize_link_incoherent_ht
sysinfo-link_pair_num=0x1
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x75
pos=0x52, unfiltered freq_cap=0x7f
pos=0x52, filtered freq_cap=0x7f
freq_cap1=0x75, freq_cap2=0x7f
dev1 old_freq=0x6, freq=0x6, needs_reset=0x0
dev2 old_freq=0x6, freq=0x6, needs_reset=0x0
width_cap1=0x11, width_cap2=0x11
dev1 input ln_width1=0x4, ln_width2=0x4
dev1 input width=0x1
dev1 output ln_width1=0x4, ln_width2=0x4
dev1 input|output width=0x11
old dev1 input|output width=0x11
dev2 input|output width=0x11
old dev2 input|output width=0x11
after ht_optimize_link for link pair 0, reset_needed=0x0
after optimize_link_read_pointers_chain, reset_needed=0x0
mcp55_num:01
Ram1.00
setting up CPU 00 northbridge registers
done.
Ram2.00
sdram_set_spd_registers: paramx :000cef10
Enable 64MuxMode BurstLength32
Unbuffered
266MHz
266MHz
set_ecc spd_device: 0x53
Interleaving disabled
RAM end at 0x0008 kB
Ram3
ECC enabled
Initializing memory: done
Setting variable MTRR 2, base:0MB, range: 512MB, type WB
set DQS timing:RcvrEn:Pass1: 00
CTLRMaxDelay=06
done
set DQS timing:DQSPos: 00
TrainDQSRdWrPos: buf_a:000ce9d0
TrainDQSPos: MutualCSPassW[48] :000ce8b8
TrainDQSPos: MutualCSPassW[48] :000ce8b8
TrainDQSPos: MutualCSPassW[48] :000ce8b8
TrainDQSPos: MutualCSPassW[48] :000ce8b8
done
set DQS timing:RcvrEn:Pass2: 00
CTLRMaxDelay=5a
done
Total DQS Training : tsc [00]=151d874b
Total DQS Training : tsc [01]=159134eb
Total DQS Training : tsc [02]=19f3270b
Total DQS Training : tsc [03]=1a93b1df
Ram4
v_esp=000cef58
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... DoneM
INIT detected from --- { APICID = 00 NODEID = 00 COREID = 00} ---
Issuing SOFT_RESET...
coreboot-4.0-2082-gccf28ba Tue Mar 6 14:42:21 CET 2012 starting...
*sysinfo range: [000cf000,000cf730]
bsp_apicid=0x00
Enabling routing table for node 00 done.
Enabling UP settings
coherent_ht_finalize
done
core0 started:
started ap apicid: * AP 01started
SBLink=00
NC node|link=00
entering optimize_link_incoherent_ht
sysinfo-link_pair_num=0x1
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x75
pos=0x52, unfiltered freq_cap=0x7f
pos=0x52, filtered freq_cap=0x7f
freq_cap1=0x75, freq_cap2=0x7f
dev1 old_freq=0x6, freq=0x6, needs_reset=0x0
dev2 old_freq=0x6, freq=0x6,
[coreboot] MSI-Motherboard MS-6340
Hello folks, i have a motherboard which i could not find on the table of supported motherboards, so i did the Steps described in he FAQ: Step 1: i did dmidecode | grep -C3 'Base Board Information' and got this: Base Board Information Manufacturer: MICRO-STAR INTERNATIONAL CO., LTD Product Name: MS-6340(VT8363) Version: Serial Number: hope that is enough Step 2: lspci -tvnn gives me this: -[:00]-+-00.0 VIA Technologies, Inc. VT8363/8365 [KT133/KM133] [1106:0305] +-01.0-[01]00.0 ATI Technologies Inc 3D Rage Pro AGP 1X/2X [1002:4742] +-07.0 VIA Technologies, Inc. VT82C686 [Apollo Super South] [1106:0686] +-07.1 VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] +-07.2 VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] +-07.3 VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] +-07.4 VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] [1106:3057] +-0a.0 Realtek Semiconductor Co., Ltd. RTL-8029(AS) [10ec:8029] \-0f.0 Ensoniq 5880B [AudioPCI] [1274:5880] Step 3: superiotool -dV says this: superiotool r6637 Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0x, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0x, rev=0xff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0x, id=0x Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0x, id=0x Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0x, id=0x Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0x, id=0x Probing for ITE Super I/O (init=standard) at 0x25e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x25e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x25e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x25e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x25e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=standard) at 0x2e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x2e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x2e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x2e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=standard) at 0x4e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x4e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x4e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x4e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=legacy/it8661f) at 0x370... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=legacy/it8671f) at 0x370... Failed. Returned data: id=0x, rev=0xf Probing for NSC Super I/O at 0x2e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x4e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x15c... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x164e... Failed. Returned data: port=0xff, port+1=0xff Probing for Nuvoton Super I/O at 0x164e... Failed. Returned data: chip_id=0x Probing for Nuvoton Super I/O (sid=0xfc) at 0x164e... Failed. Returned data: sid=0xff, id=0x, rev=0x00 Probing for Nuvoton Super I/O at 0x2e... Failed. Returned data: chip_id=0x Probing for Nuvoton Super I/O (sid=0xfc) at 0x2e... Failed. Returned data: sid=0xff, id=0x, rev=0x00 Probing for Nuvoton Super I/O at 0x4e... Failed. Returned data: chip_id=0x Probing for Nuvoton Super I/O (sid=0xfc) at 0x4e... Failed. Returned data: sid=0xff, id=0x, rev=0x00 Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e...
[coreboot] SuperIO dump for Winbond W83627EHF/EF/EHG/EG (A8V-VM motherboard)
Hi. I have motherboard Asus A8V-VM: http://www.asus.com/Motherboards/AMD_Socket_939/A8VVM/#specifications Do you think it will works with coreboot? Here is the superiotool dump: sudo superiotool -d superiotool r3844 Found Winbond W83627EHF/EF/EHG/EG (id=0x88, rev=0x63) at 0x2e Register dump: idx 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f val 88 63 ff 00 00 00 00 ff 50 04 01 00 f3 21 00 ff def 88 MM ff 00 MM 00 MM RR 50 04 00 RR 00 21 00 00 LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 f2 f4 f5 val 01 03 f0 06 02 0e 00 ff 00 00 def 01 03 f0 06 02 8e 00 ff 00 00 LDN 0x01 (Parallel port) idx 30 60 61 70 74 f0 val 01 03 78 07 03 3a def 01 03 78 07 04 3f LDN 0x02 (COM1) idx 30 60 61 70 f0 val 00 03 f8 04 00 def 01 03 f8 04 00 LDN 0x03 (COM2) idx 30 60 61 70 f0 f1 val 01 02 f8 03 00 40 def 01 02 f8 03 00 00 LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 72 f0 val 00 00 00 00 00 00 00 83 def 01 00 60 00 64 01 0c 83 LDN 0x06 (Serial flash interface) idx 30 62 63 val 00 ff ff def 00 00 00 LDN 0x07 (GPIO 1, GPIO 6, game port, MIDI port) idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 f7 val 00 02 01 03 30 09 ff ff ff ff ff ff ff 00 def 00 02 01 03 30 09 ff 00 00 00 ff 00 00 00 LDN 0x08 (WDTO#, PLED) idx 30 f5 f6 f7 val 00 ff 00 ff def 00 00 00 00 LDN 0x09 (GPIO 2, GPIO 3, GPIO 4, GPIO 5, SUSLED) idx 30 e0 e1 e2 e3 e4 e5 f0 f1 f2 f3 f4 f5 f6 f7 val 01 ff ff ff 1f b8 00 ff ff ff 09 ff ff ff ff def 00 ff 00 00 ff 00 00 ff 00 00 00 ff 00 00 00 LDN 0x0a (ACPI) idx 30 70 e0 e1 e2 e3 e4 e5 e6 e7 e8 f2 f3 f4 f6 f7 val 01 00 01 00 ff 00 00 02 1c 10 09 7d 00 00 00 00 def 00 00 01 00 ff 08 00 RR 00 00 RR 7c 00 00 00 00 LDN 0x0b (Hardware monitor) idx 30 60 61 70 f0 f1 val 01 02 90 00 c1 3f def 00 00 00 00 c1 00 Best Regards Bartosz -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] OT: how to burn commercial BIOS image into new chip?
Hi list, Question for everyone. I have a system, System A, that is very similar to System B. System A comes with a WinCE BIOS, but I have a binary Award BIOS image from System B that I wish to test on System A. The flash parts from both systems are the same size. Is there some secret to burning a binary BIOS image file into a new, blank flash chip? I burned the image to a chip, but the system does nothing when powered on. What am I missing? thanks!-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SMP stop_this_cpu and AP_IN_SIPI_WAIT
we would need to track down the first appearance of the IPI code and try to figure out why it's there. I just don't recall. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems with Winnet G270 Board / Igel Thin Client 3210 need help
Who can help to change the speed_translation function.
Here is the log ...
Initializing CPU #0
CPU: vendor Centaur device 6a9
CPU: family 06, model 0a, stepping 09
Detected VIA Model A Eden
Enabling improved C7 clock and voltage.
Voltage: 844mV (min 844mV; max 844mV) -- That is all correct
CPU multiplier: 4x (min 4x; max 6x) -- multiplier should be 6
msr.lo = 4000409
-- here the function compares the values
there is no VIA Eden 600MHz CPU in c7a_speed_translation so
new msr.lo = 409
Current voltage: 844mV -- right
Current CPU multiplier: 4x -- wrong, should be 6
For Via Model A Eden I have to change the
static int c7a_speed_translation[] = {
// LFM HFM
0x0409, 0x0f13, // 400MHz, 844mV -- 1500MHz, 1.004VC7-M
0x0409, 0x1018, // 400MHz, 844mV -- 1600MHz, 1.084V
0x0409, 0x0c18, // 533MHz, 844mV -- 1600MHz, 1.084V
0x0409, 0x121c, // 400MHz, 844mV -- 1800MHz, 1.148V
0x0409, 0x0e1c, // 533MHz, 844mV -- 1860MHz, 1.148V
0x0409, 0x141f, // 400MHz, 844mV -- 2000MHz, 1.196V
0x0409, 0x0f1f, // 533MHz, 844mV -- 2000MHz, 1.196V
0x0406, 0x0a06, // 400MHz, 796mV -- 1000MHz, 796mV C7-M ULV
0x0406, 0x0a09, // 400MHz, 796mV -- 1000MHz, 844mV
0x0406, 0x0c09, // 400MHz, 796mV -- 1200MHz, 844mV
0x0406, 0x0f10, // 400MHz, 796mV -- 1500MHz, 956mV
};
LFM is 0x0409 but I`m unsure for HFM
and should I change the c7d_speed_translation, too?
chris
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC project ideas
Hi Carl-Daniel, I don't qualify as GSoC student (too old ;) ). For sure I can't be mentor because I am absolute newbie here, but I am interested to find out If I can help with one of those projects. I know the theory how those things are working, but I have zero experience. Do you think I can be useful even if it is outside the GSoC program? Thanks, Svetoslav Trochev On Sat, Mar 10, 2012 at 12:27 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: Hi, given the lack of affordable and available hardware tools for coreboot development, I propose to look for a different set of projects this year: Tools which would help developers, and which are usable especially with current hardware. A list of ideas follows. - Flash ICE device with SPI support. - Flash ICE device with LPC/FWH support. - Serial emulation for LPC buses on a configurable I/O port with USB output on the other side. - Dual serial emulation for two LPC buses either on the same device or with two identical devices and a fast bus in between. - Serial emulation for PCI buses (i.e. PCI/serial card). The reason for the flash ICE devices is obvious: Avoid external reflashing while you're developing. The serial emulation or similar POST code port emulation is meant to provide a serial console, a SerialICE connection and/or some POST code output channel. This is especially important for laptops where debugging can be a pain and where you usually have a LPC bus available in the MiniPCIe slot. The dual serial emulation for two LPC buses would work as a fast PC-to-PC connection for SerialICE and other purposes where you need low latency, not necessarily high throughput. The serial emulation for PCI buses would complement the serial emulation for LPC to provide an easy way to connect to a SerialICE instance on the other side. As a basis for all those ideas I'd propose the Openbench logic sniffer. It has a fast FPGA, enough gates and roughly 32 kByte RAM. The FPGA is fast enough and big enough to accommodate the necessary logic, and we could easily attach a fast (66+ MHz) SPI flash chip to it. And with $50 incl. shipping the OLS is not extremely cheap, but worth its price and easily available. Fast flash chips are also available for reasonable prices. All of those projects would not result in any coreboot code, but they would make development easier, and that's a value in itself, especially now that we're porting coreboot to laptops where a LPC bus may be the only easily available bus at startup. Comments? Do we have mentors who can review VHDL/Verilog? Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC project ideas
On 03/12/12 19:07, Svetoslav Trochev wrote: Hi Carl-Daniel, I don't qualify as GSoC student (too old ;) ). For sure I can't be I don't think age matters, as long as you are an student at a recognized school, google approves. mentor because I am absolute newbie here, but I am interested to find out If I can help with one of those projects. I know the theory how those things are working, but I have zero experience. Do you think I can be useful even if it is outside the GSoC program? Thanks, Svetoslav Trochev On Sat, Mar 10, 2012 at 12:27 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: Hi, given the lack of affordable and available hardware tools for coreboot development, I propose to look for a different set of projects this year: Tools which would help developers, and which are usable especially with current hardware. A list of ideas follows. - Flash ICE device with SPI support. - Flash ICE device with LPC/FWH support. - Serial emulation for LPC buses on a configurable I/O port with USB output on the other side. - Dual serial emulation for two LPC buses either on the same device or with two identical devices and a fast bus in between. - Serial emulation for PCI buses (i.e. PCI/serial card). The reason for the flash ICE devices is obvious: Avoid external reflashing while you're developing. The serial emulation or similar POST code port emulation is meant to provide a serial console, a SerialICE connection and/or some POST code output channel. This is especially important for laptops where debugging can be a pain and where you usually have a LPC bus available in the MiniPCIe slot. The dual serial emulation for two LPC buses would work as a fast PC-to-PC connection for SerialICE and other purposes where you need low latency, not necessarily high throughput. The serial emulation for PCI buses would complement the serial emulation for LPC to provide an easy way to connect to a SerialICE instance on the other side. As a basis for all those ideas I'd propose the Openbench logic sniffer. It has a fast FPGA, enough gates and roughly 32 kByte RAM. The FPGA is fast enough and big enough to accommodate the necessary logic, and we could easily attach a fast (66+ MHz) SPI flash chip to it. And with $50 incl. shipping the OLS is not extremely cheap, but worth its price and easily available. Fast flash chips are also available for reasonable prices. All of those projects would not result in any coreboot code, but they would make development easier, and that's a value in itself, especially now that we're porting coreboot to laptops where a LPC bus may be the only easily available bus at startup. Comments? Do we have mentors who can review VHDL/Verilog? Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] separate mailling list for gerrit mails?
On Sun, Mar 11, 2012 at 10:19:41PM -0400, Kevin O'Connor wrote: I'd prefer if they were on a separate email list. Me, too. Thanks, Ward. -- Ward Vandewege | CTO, Free Software Foundation GPG Key: 25F774AB | http://identi.ca/cure | http://fsf.org/blogs/RSS Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASRock E350M1 video option ROM?
Andrew Goodbody wrote: ] ] b) When the board arrives... ] 1) Boot MSDOS and start DOS debug ] 2) At the - prompt, enter these commands: ]-n vga.bin ]-rbx ]-1 ]-w ] 3) The option rom is vga.bin in the current directory. ] ] Thanks, ] Scott ] ]a) is good. ]b) is just going to get you 64KB of unintialised data. There is nothing ]in those instructions to access the video BIOS AFAICT. ] ]Andrew Oops, make that: -n vga.bin -rbx -1 -w c000:0 -q Thanks, Scott -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASRock E350M1 video option ROM?
HighlyCaffeinated wrote: unable to build with the crossgcc toolchain. I sidestepped by loading 10.10 on an unused machine (which appears to have been successful), but thought it should be mentioned. Logs available for the interested parties. Yes, logs are neccessary for any action to be taken. It would be nice if you could perform various xgcc experiments, to isolate the problem. This is not practical over email, but perhaps on IRC. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC project ideas
Carl-Daniel Hailfinger wrote: Tools which would help developers, usable .. with current hardware. I think the best way is to put them on the Talk:GSoC wiki page. Ie. not on the GSoC page itself, but on the discussion page for that page. - Flash ICE device with SPI support. - Flash ICE device with LPC/FWH support. - Serial emulation for LPC buses on a configurable I/O port with USB output on the other side. Sure. If there are students with a hardware interest I think these are good projects. There is also much VHDL available already. As a basis for all those ideas I'd propose the Openbench logic sniffer. Yes and no. OLS is fine as a prototyping and development platform for these projects, but it's an incredibly poor design when it comes to USB, and it doesn't fit in the expansion slot. It has a fast FPGA, enough gates and roughly 32 kByte RAM. The RAM is block RAM inside the FPGA, which can not be arbitrarily used from logic. The OLS doesn't have a separate RAM chip. One needs to be connected externally. It's not impossible, but requires some soldering skill. we could easily attach a fast (66+ MHz) SPI flash chip to it. The OLS as SPI master mux for having an easy way to flash a real chip used by a mainboard when booting is fine. But the chip should be able to reside on the mainboard, and the OLS should drive the mainboard reset while flashing. Having the OLS connect via wires means that the SPI flash can not be driven quite so fast. The shorter wires the better. The OLS is a big board with exposed contacts on the bottom. The OLS is not a good fit for installation into e.g. a laptop. This is one of the use cases for a QiProg; it's intended to be soldered into the target system, on top of, or very near, the flash chip. All of those projects would not result in any coreboot code, but they would make development easier, I think this is fine, and we've had similar project ideas already. Also some of our previous running projects have resulted in code outside of coreboot but which complements coreboot significantly. Assisting development counts too. now that we're porting coreboot to laptops where a LPC bus may be the only easily available bus at startup. I don't know that LPC is usually available, but even so it is a nice start, and VHDL already exists. Do we have mentors who can review VHDL/Verilog? Yes. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC project ideas
Hi Svetoslav, Svetoslav Trochev wrote: I know the theory how those things are working, but I have zero experience. Do you think I can be useful even if it is outside the GSoC program? For sure you can. And right now it's still only March, so if you have spent some time on these things you may certainly be qualified to mentor a student come time for SoC. What exactly would you like to work on? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASRock E350M1 video option ROM?
Extracting the vga.rom from the BIOS file appears to have gone well. The board has arrived and I am waiting for a fresh flash chip to start playing. Thank you very much for taking the time for the fishing lesson... it is very much appreciated. Many are unwilling to commit the time to teach while answering a question. I took the time to look up the recommended debug commands, and from what I learned I was left curious where the data source was specified. Given the corrections I think I get it now. Thanks for that as well! I will make a concerted effort to catch someone on IRC in the next few days to give it a look. I'm curious as to the fault, and I am certain I will learn a lot in the process. Thanks again! -Todd From: Peter Stuge pe...@stuge.se To: coreboot@coreboot.org Sent: Monday, March 12, 2012 8:21 PM Subject: Re: [coreboot] ASRock E350M1 video option ROM? HighlyCaffeinated wrote: unable to build with the crossgcc toolchain. I sidestepped by loading 10.10 on an unused machine (which appears to have been successful), but thought it should be mentioned. Logs available for the interested parties. Yes, logs are neccessary for any action to be taken. It would be nice if you could perform various xgcc experiments, to isolate the problem. This is not practical over email, but perhaps on IRC. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
