On 05/30/2013 01:45 PM, Cristian Măgherușan-Stanciu wrote:
> Wow, I can't believe I was so close to the commit before the fork ;-D
>
> I also think this is a good strategy, please keep us posted on any progress.
>
Peter and Cristi, thank a bunch for your help. Your suggestions helped
me a lot in reaching the following conclusions.
I tried a couple of things, as Peter suggested. I managed to build a ROM
from their tree. It didn't work since it was written for a different
board. I pulled in the romstrap table from my board, and the early
serial init. That also didn't work. It could be that their code
reconfigures the cpu to nb bus in a way not suited for my board; I
haven't dug too deeply into the issue. That configuration is best left
in the romstrap.
Since the raminit code is fairly isolated, I pulled it into my branch,
and spent about half a day getting it to compile. I spent a little time
finding out why the meat of raminit code is not called, until I found
out it was looking for a SO-DIMM. That's already a red flag.
The code from VIA has a ton of tables with delays and driving values for
DRAM. The most important parameter, how much to wait before reading each
set of DQ pins, is also preset. That preset is different than what I
have been using. Needless to say, raminit fails. The presets are
board-specific.
Other than the presets, I can't see anything fundamentally different
from the raminit algorithm that's on gerrit. I don't think the effort of
rebasing the VIA code is worth the benefits (not even sure there are any
benefits -- the gerrit code does the same thing with 20 times less LOC).
I'll have to play around with it some more, see if I can get it working.
Right now, it looks like the VIA code serves better as a HOWTO (or
HOWNOTTO) guide.
Will post updates (either here or on IRC).
Alex
P.S. Limited time offer: Free tickets to join the fun for anyone with a
VX900 board.
Hi,
I am that guy that never seems to get VX900 working properly. I've
recently received some code[1] for the VX900 from VIA. It is based on a
coreboot fork from about 2009.
Rather than try to continue my own VX900 effort, I think it is better to
use the code provided by VIA, and clean that one up.
I don't have the SVN history for the code, but Cristi was able to trace
it back to somewhere around hash a9c5ea08d07d343d32d4c083a232107bd84d8064
VIA has no interest in maintaining or rebasing the code, so we're on our
own here. The good news is that using this code will reduce the time
needed to complete the VX900 port significantly.
I therefore ask the gurus, "What is the best way to go about this?"
Let's hope we can get this code working with our current master. If we
manage to rebase it, I can clean it up, and optimize it a bit.
Alex
[1] http://g-tech.no-ip.org/~mrnuke/coreboot_vx900_vt8595a.tgz
Marius Schäfer wrote:
> Can you read anything out of these lines and help me?
..
> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 63MB of RAM.
> ------------[ cut here ]------------
> WARNING: at arch/x86/kernel/cpu/mtrr/cleanup.c:971
> mtrr_trim_uncached_memory+0x411/0x42e()
> Pid: 0, comm: swapper Not tainted 3.2.44 #7
> Call Trace:
> [<c1017964>] ? warn_slowpath_common+0x63/0x74
> [<c12f98f2>] ? mtrr_trim_uncached_memory+0x411/0x42e
> [<c10179f8>] ? warn_slowpath_null+0xd/0x11
> [<c12f98f2>] ? mtrr_trim_uncached_memory+0x411/0x42e
> [<c12f5165>] ? setup_arch+0x4eb/0x9dd
> [<c12f3421>] ? start_kernel+0x5e/0x275
> ---[ end trace 4eaa2a86a8e2da22 ]---
As Ron says, work on fixing this MTRR problem.
> update e820 for mtrr
> modified physical RAM map:
> modified: 0000000000000000 - 0000000000001000 type 16
> modified: 0000000000001000 - 00000000000a0000 (reserved)
> modified: 0000000000100000 - 0000000004000000 (reserved)
> modified: 0000000004000000 - 000000001dfe0000 (usable)
> modified: 000000001dfe0000 - 000000001e000000 type 16
> last_pfn = 0x1dfe0 max_arch_pfn = 0x100000
> Kernel panic - not syncing: Cannot allocate trampoline
>
> Pid: 0, comm: swapper Tainted: G W 3.2.44 #7
> Call Trace:
> [<c12245eb>] ? panic+0x57/0x12a
> [<c12f77e7>] ? setup_trampolines+0x40/0xb1
> [<c12f51df>] ? setup_arch+0x565/0x9dd
> [<c12f3421>] ? start_kernel+0x5e/0x275
Check the kernel source to find out what the constraints are for that
trampoline allocation. Maybe it must be in some region where there
isn't any available RAM, which would be a bug in the memory map for
this (and more?) mainboards.
Try to find out more details.
//Peter
Dear coreboot folks,
Am Donnerstag, den 30.05.2013, 01:57 +0200 schrieb gerrit code review:
From <http://review.coreboot.org/3336>:
> Change subject: gitconfig: Add sample checks shipped by git to pre-commit hook
> ......................................................................
>
>
> Patch Set 2: Code-Review-2
>
> It does not make sense to have a hook that checks a tree-wide policy
> and then allow that policy to be disabled by configuration. Either we
> decide on the filename policy or we do not need the hook.
as non-ASCII characters are not allowed in our source [1], I assume they
are also not allowed in file names.
The sample pre-commit hook shipped by git has a check for non-ASCII file
names, which can be disabled by a config option.
Are there any circumstances where non-ASCII characters might be needed?
If not, Peter is right and the option can be removed from the script,
which I would do then.
Thanks,
Paul
[1] http://review.coreboot.org/2604
Hi George,
The chip is there and it was easy to find it, but it's a less common
package. It is an 8 pin part but wider and closer to the surface than the
SOIC8. I tried the Pomona clip and even if the pins would match after
mounting the clip, it makes no electric contact to it due to the smaller
leads, so Flashrom couldn't detect it.
The next step is to solder some wires and make it writable from outside
using my RaspberryPi external flasher.
The rest of the hardware is quite well supported by coreboot. It is somehow
similar to Roda rk9 (same CPU package, NB and SB) but with the rest of the
chips(EC and company) similar to other Thinkpad laptops, so in theory a
port should not be so hard.
Cristi
On Wed, May 29, 2013 at 3:26 AM, George Chriss <gschriss(a)gmail.com> wrote:
> On Sun, May 26, 2013 at 6:39 AM, Cristian Măgherușan-Stanciu <
> cristi.magherusan(a)gmail.com> wrote:
> >
> > Hi,
> >
> > Please see the attached files, gathered while running the proprietary
> BIOS.
> >
> > Cheers,
> > Cristi
>
> Hi,
>
> Is the W25X64 chip physically accessible with exposed surface-mount pins?
> A Bus Pirate may be helpful/necessary to gather additional info and to
> reprogram the chip.
>
> Photos from an X201i + Bus Pirate:
> http://gchriss.tumblr.com/post/50463745980/a-closer-look
>
> Sincerely,
> George
>
>
> >
> > --
> > coreboot mailing list: coreboot(a)coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
>
>
a few things.
Don't know why the MTRRs are not supporting all of memory but you
ought to fix that.
Can you get rid of the vga bios? That will save some time.
I forget the last thing :-)
oh yeah, when you get it for real, turn down the default console log
level to ERR. Printing takes a surprising amount of time.
ron
A new stable release of SeaBIOS (version 1.7.2.2) has been tagged.
This release contains bug fixes.
The release is available via git:
git clone git://git.seabios.org/seabios -b 1.7.2-stable
-Kevin
Asias He (2):
virtio-scsi: Pack struct virtio_scsi_{req_cmd,resp_cmd}
virtio-scsi: Set _DRIVER_OK flag before scsi target scanning
Kevin O'Connor (1):
Cache boot-fail-wait to avoid romfile access after POST.
boot.c | 15 +++++++++------
virtio-scsi.c | 5 +++--
virtio-scsi.h | 4 ++--
3 files changed, 14 insertions(+), 10 deletions(-)
> -----Original Message-----
> From: ron minnich [mailto:rminnich@gmail.com]
> Sent: Wednesday, May 29, 2013 12:17 PM
> To: Deucher, Alexander
> Cc: Rudolf Marek; David Hubbard; Coreboot
> Subject: Re: [coreboot] Native init for AMD cards
>
> well, we're lighting up 4 laptop panels from source today. So it's doable.
Right. My point is just that there's not some special atom function you can call to do all of that. You have to walk the topology and light up the displays.
Alex
Hi David,
> I read the kernel sources today, looking for a way of doing native init for
AMD boards like the F2A85-M.
> Comments welcome on the insanity of this proposal :)
In fact I did the same some time ago, but there is a problem with the AtomBIOS
and the graphical data paths.
> 2. Do coreboot developers have contact with the radeon driver developers? A
> little nudge from time to time could keep a project like this on track.
I was speaking with Alex (I put him on CC) My Q was:
> My plan (which may sound bit naiive), is/was to Initialize the GPU with
> AsicInit (so simple run of AtomBIOS interpreter) and then switch it to legacy VGA
> mode and handle this with SeaBIOS VGA BIOS. Maybe there is a gap between -
> setting up a legacy VGA and AsicInit, I don't know, possibly I need to detect
what kind of output is used, but all I need is simple text mode
>
> Please can you throw some light on this topic?
Alex told me:
The AsicInit table just performs low level setup on the asic, it doesn't mess
with the displays at all. The radeon vbios has real mode x86 code that gets
executed at post or via vbe calls to read in the information in the atombios
tables, figure out the display topology and detect and light up whatever
displays are attached. You would need to implement that functionality in your
vbios replacement. If you want a bios console, you'll have to use the open
source radeon driver as a guide to how to write a vbios replacement that
enumerates and lights up the displays.
END
Also it turned out that the bytecode is there for the OEM so the changed
topology does not need the new VBIOS assembly but just the AtomBIOS bytecode.
Which is quite bad, because the VBIOS is depending on how it is routed and may
only work with similar boards even when chipset is same. We would have to find
out a way how to include the AtomBIOS in some form in the coreboot or re-write
it somehow, because the bytecode is not even "property" of AMD but OEM and
radeon driver needs that to be present in a rom. Maybe it would be possible to
write some commmon init and handle just small changes in the bytecode.
For now, I would say kind of "reply" init might work, it depends if your goals
are similar like we have with intel, so just graphic framebuffer for grub2 or
something like I had in my mind.
Thanks
Rudolf
