Am 14.10.2014 um 15:29 schrieb WANG FEI:
> I've sent out for Wiki access few days ago, but still have not got any response yet.
Oh sorry, I missed that. Please send me your desired user name by private mail.
I had first success with my pomona clip, today. Sadly, the mobo does
not have any UART, so I'll finally have to switch to something more
advanced. I've a high-speed ftdi usb adapter board that can be used
as USB debug device, but this will need some code changes along with
some refactoring. I think, I'll focus on that during the hackathon.
It would be nice, to have some more usb debug devices available for
Lin, Ryan wrote:
> If we add aligned(4) to the define as the following :
> #define BOOT_STATE_INIT_ATTR __attribute__ ((used, aligned(4), section (".bs_init)))
> We can get 4-byte alignment for .bs_init.
> What is your thoughts on this?
Is that a GCC extension?
The coreboot codebase also supports other compilers.
It should be unpatched GCC 4.9, and I found out that .bs_init is force 32-byte alignment with GCC 4.9.
Dump from ramstage.o
12 .bs_init 000000c8 00000000 00000000 00036160 2**5
CONTENTS, ALLOC, LOAD, RELOC, DATA
As the result, padding datd is added to mrc_cache_update, pch_log and cbmem_bscb.
0001d1d0 T _bs_init_begin
0001d1e0 t mrc_cache_update <- 32 bytes
0001d200 t pch_log <- 32 bytes
0001d220 t finalize
0001d248 t spi_init_bscb
0001d25c t cbmem_bscb <- 36 bytes
0001d280 t disable_rom_cache_bscb
0001d2a8 T _bs_init_end
If we add aligned(4) to the define as the following :
#define BOOT_STATE_INIT_ATTR __attribute__ ((used, aligned(4), section (".bs_init)))
We can get 4-byte alignment for .bs_init.
What is your thoughts on this?
something seems wrong with this one:
On 25.08.2014 23:33, gerrit(a)coreboot.org wrote:
> the following patch was just integrated into master:
> commit 8414d3c0b407d9afc6a2446dba3ca358da2c7bb6
> Author: Aaron Durbin <adurbin(a)chromium.org>
> Date: Thu Oct 10 12:44:11 2013 -0500
> xcompile: always use -march=i686
> When compiling coreboot for x86 on gcc the compiler is
> free to pick whatever defaults it is using at the time of
> gcc's compile/configuration when no -march is specified.
> Not properly specifying -march then opens up the use of SSE
> instructions for compilation units it should not be used such
> as the SMM module as this module doesn't save/restore SSE
> Change-Id: I64d4a6c5fa9fadb4b35bc7097458e992a094dcba
> Signed-off-by: Aaron Durbin <adurbin(a)chromium.org>
> Reviewed-on: https://chromium-review.googlesource.com/172640
> Reviewed-by: Stefan Reinauer <reinauer(a)google.com>
> (cherry picked from commit d49358f7959bb52c3e7ff67d37c21a1b294adf72)
> Signed-off-by: Isaac Christensen <isaac.christensen(a)se-eng.com>
> Reviewed-on: http://review.coreboot.org/6716
> Tested-by: build bot (Jenkins)
I bisected a no-serial-output problem on a kontron/986lcd-m with a Core
Duo (Yonah) CPU, leading to this commit. I don't see what is going wrong
here. Core Duo is obviously kind of i686, but specifying -march=i386
works around the problem. So far I haven't spotted any differences in
generated code (other than reordering).
If I don't specify -march=, the reference toolchain seems to generate
the same code as with -march=i386. Maybe we should default to that?
Also, I was told, that if you specify -march=, the compiler may use CPU
features that have to be enabled first.
ron minnich wrote:
> I'm hoping some of you will be there. I'd love it if some of you could
> stand up and tell us what you're doing.
> It's Monday at I believe 415pm -- check the schedule, don't trust me :-).
Schedule says it's Monday (tomorrow) at 5:30pm.
"reduce the boot time to the minimum possible" -- what's that mean. Do
you have a number?
ARMs boot linux to usability in 800 ms. (number seen at FOSDEM in
2007). Is that fast enough?
SPI greatly increases time to boot, and the use of SPI may be more
important than the boot loader used.
Finally, in real world use, the static timing loops and serialization
of request/response actions of simple boot loaders may make them
slower than Linux. We found that linux could pull multi-megabye
kernel+initrd downloads over the network about 10x faster than
etherboot could back in 2002. Linux has internal concurrency that can
be very effective.
Which is to say, just saying 'filo is faster' is very simplistic,
especially absent hard numbers and some real measurements. Getting
boot time down is complex and can't be reduced to a buzzphrase.
On 12.10.2014 18:21, Vipin Gahlaut wrote:
> Logs for the problem I am getting repeatedly at run time
> change on port 1
> fullspeed device
> first get_descriptor(DT_DEV) failed
> set_address failed
That's exactly what I observed on a kontron/986lcd-m (i945) with low-
speed devices connected to the UHCI. Are you using a similar platform?
We have to reduce the boot time to minimum possible; hence the preference
Not sure the status of USB stuff in GRUB2 so trying hard to get FILO to
On Sun, Oct 12, 2014 at 10:12 PM, ron minnich <rminnich(a)gmail.com> wrote:
> you can try to get filo to work, or you can work at John Lewis
> excellent work on JELTKA and see if you would be better off using a
> linux kernel instead.
> My bias is towards JELTKA, personally.