> I use gcc-4.4.7 version. I also tryed to use gcc-4.6.3 and it didn't make
> any results also.
Did you use coreboot's reference toolchain or was it a gcc-4.6.3 from
your distribution? If you didn't try the reference toolchain yet,
it's worth it.
To build the reference toolchain, simply run
from your coreboot top-level directory, and wait... abuild should use it
automatically. For your manual make runs, you should remove `.xcompile`
once the toolchain is build.
> I don't understand the reasin why it may happen.
Me neither. Maybe you should also try to reset your coreboot checkout
or even a fresh checkout if you did any changes.
M. Sc. Nico Huber
secunet Security Networks AG
Tel.: +49-201-5454-3635, Fax: +49-201-5454-1325
Mergenthalerallee 77, 65760 Eschborn, Deutschland
Sitz: Kronprinzenstraße 30, 45128 Essen, Deutschland
Amtsgericht Essen HRB 13615
Vorstand: Dr. Rainer Baumgart (Vors.), Willem Bulthuis, Thomas Pleines
Aufsichtsratsvorsitzender: Dr. Karsten Ottenberg
I am porting coreboot to our own product(Vortex86EX). I see there is a
function called "hard_reset". Some boards implements this function, and
some don't. Looks like each different mainboard has different
implementation of hard_reset.
Now I just wrote a blank hard_reset function, but maybe it is not right.
So what is the purpose of this function? What should I put inside this
function? To reset the system, why not just use system port(92h port)?
I've noticed some trends in CLs from our newer guys that I want to
warn against. People are putting in text that, viewed from a short
time frame and a perspective of being unfamiliar with the code base
and hardware, make sense. But from the longer time frame, they're not
such a good idea.
A little background: the coreboot codebase started on sf.net, in 1999.
SInce that time, we have
- used 4 SCM systems (CVS, ARCH, subversion, GIT)
- run on at least two different servers (sf.net, coreboot.org)
- supported around 10 kernels (Linux, Plan 9, *BSD, windows variants, QNX, ...)
- - and over 100 different linux versions
- worked with at least 10 vendors who no longer exist
Writing CLs that stand the test of time in this context is a bit of
challenge. But there are
some things you can avoid:
1. Avoid URLs as much as possible. There are 600 URLs in the 21000
u-boot commit log.
There are 224 in the 4000 or so coreboot commit log. Of those in
coreboot, 40 or so are invalid. This problem only gets worse with
time. Some of them are for dead companies, others because things have
2. avoid kernel boot logs. Sure, it means something to you, right now.
But it's useless after
about a year, as kernels change. It can be quite misleading over
time. And, besides,
there are people out there who do not care about Linux and don't
want to trawl through
Linux boot logs to understand a CL. Avoid being linux-centric
3. avoid coreboot logs. Same reason. It's amazing how much coreboot
logs change over time.
4. Avoid copy/paste of documents. Not the least because we don't want
to deal with copyright issues
5. A CL is not a tutorial. It's not a chance to thank people for their
work. It's an explanation
of a change. Keep it short. In many cases, it should be possible
to understand it from the
summary. For most of them, I should not have to click through a URL
to have some idea of what you've done! See gerrit.chromium.org for an
example of a real, large project and what their CLs look like.
6. And, I hope for obvious reasons, never link to a patent, cite a
patent, or mention patents as the basis of anything you do :-)
7. Avoid telling people to run this or that tool. Not everyone has
8. Finally, we almost never need to see gcc/iasl error messages. The
words 'won't compile' are just fine in almost every case.
1. create a clean, concise summary
2. explain what you did
3. explain why you did it.
(2 and 3 can be in the other order)
I hope Nico doesn't mind, but I've just been reviewing and his CLs are
fresh in my mind. They're a great model of how CLs should be written.
So check his CLs out. Hope you do not mind me mentioning you, Nico!
I did a (web) search to discover who sells the RK9. I didn't found shops that sell that
laptop. Does someobdy who sells it (either online or physical shop)?
ps: I did the same about the Getac P470 with the same results: nobody seems to sell it.
Thank in advance,
Again, can we cut this down a bit? Most of what you're saying is
obvious or gratuitous. It's very kind of you to thank people but we
really don't need thanks in the message.
On Tue, Jul 2, 2013 at 1:40 AM, Paul Menzel <gerrit(a)coreboot.org> wrote:
> Paul Menzel (paulepanter(a)users.sourceforge.net) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/3587
> commit 7d396566be210dfd5f86c8d9038ae0fdacefa02f
> Author: Paul Menzel <paulepanter(a)users.sourceforge.net>
> Date: Tue Jul 2 09:54:17 2013 +0200
> lenovo/x60/romstage.c: Collect timestamps in romstage
> Collect early timestamps in Lenovo X60’s romstage.
This is fine.
> like the Lenovo T60
> does. Selecting the option `COLLECT_TIMESTAMPS` in Kconfig and then
> doing `cbmem --timestamps` should output the timestamps.
Are we going to list *all* the systems that do it? Why? Are we going
to tell people
how to use each Kconfig? Documentation of this type does not belong in
a commit message.
> Thanks to Nico Huber’s work setting this up for the ICH7 and implementing
> it for the T60, all what was needed to do, was to do the equivalent
> changes for the X60 as for the T60 in commit 44c392f8 .
> lenovo/t60: Collect timestamps in romstage
>  http://review.coreboot.org/3499
remove all this text. It's not needed. We all depend on the work of
others. We don't need to cite it in each and every CL.
the release of flashrom 0.9.7 is imminent and I would really like to
enable the Dediprog programmer by default. Carl-Daniel informed me that
the only problem is that we do not know which opcode is actually used
for reading on the SPI bus. It could be that we initiate a fast read
(0x0b) instead of a normal read (0x03). This would work with the
majority of flash chips but would not with others where flashrom
should normally work. Since we are not sure we don't want to enable it
without further consideration/testing/warning messages. Furthermore
not all chips supporting fast read have this fact noted in their
datashets. So testing any apparently non-fast read chip does not
suffice. We would rather be able to check the opcode on the SPI bus
with a logic analyzer directly. Are there any Dediprog users who can
help us with that please?
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
El 01/07/13 22:14, Reiner Luett escribió:
> On 01.07.2013 00:35, Álvaro [andor] wrote:
>> I have a batch of 10x 8mbyte chips. If you have the USB3 model of the
>> board, I can burn the original bios in one of them and send it to you.
> Do you know, if the chips are working with the E350M1 without USB3?
> Please send a discription of the chip. What kind is it?
> Winbond W25Q64BVDAIG 64Mbit in DIP8?
I substituted the included "W25Q32BVAIG 4MB PDIP 8Pin PDIP SPI" by the
equivalent in 64Mbit: W25Q64BVAIG (note there's no 'D' as the one you
said, I don't know if it was a typo on your side..), and yes, it's DIP8.
I think it should work, as there is minimal difference between the USB3
and the regular model, and I think all the controllers are the same,
except for the USB3 of course. The coreboot target I'm using is the same
But, the bios doesn't look *exactly* like the same. If anybody has a
backup for the regular E350M1 (Paul Menzel. Martin Roth...?) vendor
bios, I can burn it...
Am 25.06.2013 23:08, schrieb Dmitry Bagryanskiy:
> My processor type is Intel Core 2 Duo P8400, socket mFCPGA479M
IIRC, I've seen at least one RK9 with this CPU running coreboot.
Looking through your log files, I didn't find anything suspicious.
I'll try to check if current upstream coreboot really works on our RK9,
tomorrow. Meanwhile, could you post your coreboot .config? And when
responding, please always cc the coreboot mailing list.