Hi,
Im looking at picking up an old alienware with this mainboard in it. I have read that the mainboard actually supports up to 8gb ram and that it can handle a 512mg video card. It looks like you may have done some bios tweaking and such to allow for significant upgrading beyond original bios limits. If this is the case wondering if you would share the program. I've read that this mainboard seems to have issues with seeing new hdds larger than 120gb(at least in the alienware model I'm looking at) and I'm hoping that among other improvements if you have made a bios upgrade that it might also address this issue.
Thank you in advance,
Erika
Sent from my Sprint Samsung Galaxy® Note 4.
Dear Timothy,
thanks again for improving the support for the ASUS KFSN4-DRE and being
so responsive. It’s a great example for how to work with upstream!
You uploaded the board status output [1] with commit 8057285 [2].
Thanks!
But, it looks like a lot of information is missing from the coreboot
console messages, like it was cut. Could you upload another run with the
same commit or, for example, from latest master?
Does `util/cbmem/cbmem -c` show all messages? You’d need to enable CBMEM
console in Kconfig for that though. (SeaBIOS is also able to write its
messages to CBMEM console.)
Lastly, you put the time stamps on the Wiki page [3]. Could you please
also upload those into the board status repository as people expect such
information to be there? They would probably not go looking in the Wiki
and in the board status repository the time stamps can be mapped to a
specific commit.
10:start of ramstage 20,261
30:device enumeration 25,566 (5,304)
40:device configuration 50,219 (24,653)
50:device enable 108,559 (58,339)
60:device initialization 109,734 (1,175)
70:device setup done 1,056,523 (946,789)
75:cbmem post 1,057,578 (1,054)
80:write tables 1,058,641 (1,063)
90:load payload 1,064,180 (5,539)
99:selfboot jump 1,123,383 (59,202)
Looking at the actual time stamps below do you see from your logs why
the device initialization takes almost one second? As the timings on the
Wiki page [3] show, it’s not related to enabling graphics/VGA.
I guess SeaBIOS executes fairly quickly too? Do you have timing data for
that as well? Or do you use COMBOOT as a payload?
Just for comparison, how long does the vendor firmware take to get to
COMBOOT [4] or whatever you use?
Thanks,
Paul
[1] http://review.coreboot.org/gitweb?p=board-status.git;a=commitdiff;h=96b9b...
[2] http://review.coreboot.org/8270
[3] http://coreboot.org/Board:asus/kfsn4-dre
[4] http://www.syslinux.org/doc/comboot.txt
Hello!
Okay, I'll send them along to the list where we should be having this
conversation.
-----
Gregg C Levine gregg.drwho8(a)gmail.com
"This signature fought the Time Wars, time and again."
On Wed, Feb 11, 2015 at 7:18 PM, Benny <benediktwindolph(a)gmail.com> wrote:
> I attached 2 files, i hope it contains the required information.
> If there is something missing let me know.
>
>
> Am Mittwoch, den 11.02.2015, 18:59 -0500 schrieb Gregg Levine:
>> Hello!
>> How about you do us the favor of telling us more about your laptop?
>> You will need to run certain programs or use specific Linux commands
>> to tell us what the laptop wears.
>>
>> Please note that the majority of laptops wear specialty chips who are
>> specifically configured to run those features that enable the special
>> functions that make them different from desktop motherboards.
>>
>> For example there is an embedded controller involved who handles those
>> functions, and typically information is not involved.
>>
>> The one of the Linux commands are #lspci who will tell you what the
>> internal PCI bus looks like and there are others. The coreboot wiki
>> contains these, plus the programs needed, flashrom to, ah, program the
>> flash, superio to identify that part.
>>
>> Please study this site http://www.coreboot.org/Welcome_to_coreboot
>> from there you'll find out more then I can provide here. Plus you have
>> the support of these friendly people to help you further.
>>
>> My problem is that your Dell Sputnik or Dell traveler is not known to me.
>> -----
>> Gregg C Levine gregg.drwho8(a)gmail.com
>> "This signature fought the Time Wars, time and again."
>>
>>
>> On Wed, Feb 11, 2015 at 6:30 PM, Benny <benediktwindolph(a)gmail.com> wrote:
>> > Hey everyone,
>> >
>> > is there a chance coreboot comes to the Dell Sputnik (XPS13, L322X1Y1)?
>> >
>> > Thanks,
>> >
>> > Benny
>> >
>> >
>> > --
>> > coreboot mailing list: coreboot(a)coreboot.org
>> > http://www.coreboot.org/mailman/listinfo/coreboot
>
Hi,
I tried today a windows 7 installation usb stick and a cd disc.
Both 32bit and 64bit.
Both Windows' stopping at disk.sys and the hdd led on.
32bit: sometimes windows boots, most time not.
Any ideas, what's wrong?
Best,
lynxis
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)jabber.ccc.de
mobile: +4915123277221
This comes in a new thread because my ML membership was somehow hosed
coreboot-side, so I have no mail to reply to.
I have until now ignored this code of conduct. There's been talk about how
people feel unwelcome in _other_ projects, about how _other_ projects (fill in
the blank). What there hasn't been any talk of, however, is any instance where
this has been a problem in _our_ community.
coreboot _is_ a hard thing. You _do_ need a _hard_skin_ to do coreboot. That's
just the nature of our work. That is not because of our attitude; hardware is
crap. People get annoyed at it. They bash it and vent out. It's normal.
There's absolutely no point in burdening our developers with a generic code of
of conduct.
I don't know how much time Marc actually spends on IRC, but we have been great
at policing ourselves. Pretending someone else's problem as our own is just
silly. The fact is, the problem Marc pointed out, and the problems he tries to
solve with this code of conduct are non-present in our community. I've seen
more helpful people jumping to aid than in any other project. I've seen more
good will and personal time invested to help others than in any other project.
I've only seen Peter give new guys the RTFW, RTFS, or STFW, and those have
been well deserved by the person receiving them. Are we going to start taking
action against some of our most experienced and valuable developers because
they didn't waste their personal time doing someone else's homework?
There's a phenomenon of "Oh, I saw this thing here, so let's implement it
irrespective of whether or not it's actually relevant". I call that liberal
bullshit. That's exactly what this is.
This code of conduct is an insult to our hard work over the years, and an
insult to our friendly nature and countless personal hours spent helping
others. When you've put up this code of conduct, you've basically said "our
community is not capable of bettering itself by peer action and common sense,
so we need to enforce it". It degrades every person who has ever contributed,
and degrades the community as a whole. It's a degrading document that has no
place.
Alex
I knew there was something wrong to typing that from an Android phone.
It didn't get sent to the list.
-------- Forwarded Message --------
On Feb 10, 2015 2:19 AM, "Patrick Georgi" <> wrote:
> Am 10.02.2015 um 08:56 schrieb Alexandru Gagniuc:
> > That's actually the way I2C is designed to work, and this sort of
API models
> > it more accurately. Linux uses it. libeopencm uses it. spidev uses it.
> But hardware doesn't. The API is fine when you bitbang everything, but
> not when there's a controller that takes over some of the work, like
> programming the address.
>
> On such a controller, you have to pick apart struct i2c_seg* to figure
> out which elements are addresses and which are data, and split things
> into different registers.
>
Is that proper i2c or smbus controllers? Smbus is a different beast that
we really shouldn't simplify to i2c++ .
Assuming it's i2c proper, how do we handle such cases? I2c is i2c and it
makes more sense to abstract the nature of the hardware in an i2c
centric way. A silicon-specific API is the wrong way here.
I have patches in my pipeline to introduce generic i2c over displayport
aux channel code. That makes use of the low level nature of i2c_seg to
properly break down the AUX bus transactions in a hardware-agnostic way.
> I really don't see how it's useful to keep the data structures as low
> level as possible and then require drivers for more capable devices to
> uplift them to a higher abstraction level.
>
See section about abstracting hardware details above. There's no
measurable penalty for internal abstraction. There is however a penalty
for driving the hardware in a suboptimal way. That's the driver's job.
Sure, we can make a context based i2c API based on ops. Then we can
check the direct_read pointer and use that if it's not null. Though most
people will get it wrong when writing drivers. KISS.
Alex
My C720 shuts down as well. Someone in this thread suggested that it was
related to whether or not the adapter is connected:
https://productforums.google.com/forum/#!topic/chromebook-central/gjSnZJe...
I've yet to have it shut down when the adapter is connected, whether or not
the adapter is plugged into the wall. Although that's not an optimal
solution, it has removed a lot of the frustration to have a workaround.
Thanks,
Myles
On Mon, Feb 9, 2015 at 7:20 AM, Aaron Durbin <adurbin(a)chromium.org> wrote:
> On Mon, Feb 9, 2015 at 1:32 AM, Matthias Apitz <guru(a)unixarea.de> wrote:
> > El día Sunday, February 08, 2015 a las 11:14:10PM +0100, Idwer Vollering
> escribió:
> >
> >> ?
> >>
> >> 2015-02-08 21:55 GMT+01:00 Matthias Apitz <guru(a)unixarea.de>:
> >> > El día Sunday, February 08, 2015 a las 02:40:45PM -0600, Alex G.
> escribió:
> >> >
> >> >> Suspect number one is the device overheating. The shutdown is
> >> >> triggered by the EC. I don't know how you can enable ACPI debug
> output
> >> >> on BSD though. On linux, it would be "echo 1 >
> >> >> /sys/module/acpi/parameters/aml_debug_output", so whatever the
> FreeBSD
> >> >> equivalent of that is.
> >>
> >> hw.acpi.verbose=1 would be a start.
> >> ...
> >
> > Thanks for all the hints.
> >
> > As I said, the events are sporadic, seldom, but complete power-off (like
> > as you would cut the cable from the motherboard). Of course the system
> has no
> > chance to write anything to /var/log/messages or console.
> >
> > My hope while writing to coreboot@ was to get a pointer to the list of
> > open ore solved issues within coreboot and/or SeaBIOS to see if this
> > issue is somewhat known, solved or could be related to some known or
> > solved issue. Where can I find such a list which is normally (as we do
> > in my company) attached to the Release Notes of a new version of
> > software.
> >
>
> On the surface this doesn't sound like anything coreboot or SeaBIOS
> specific. Can you grab the cbmem console logs on the boot after the
> power off (cbmem -c)? There is also an eventlog sitting in memory as
> well that can be grabbed. mosys
> (
> https://chromium.googlesource.com/chromiumos%2Fplatform%2Fmosys/+/refs%2F...
> )
> should be able to do that work for you: mosys eventlog list
>
> The last thing to get is the EC console log. That's much harder to get
> as you have a kernel that doesn't have the EC driver in it. If you
> feel adventurous the tool (util/ectool) can be found here:
>
> https://chromium.googlesource.com/chromiumos%2Fplatform%2Fec/+/refs%2Fhea...
>
> Hope that helps.
>
> -Aaron
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
Hi,
we had our last big discussion about building coreboot releases in
November. It quickly moved to the topic of removing boards that don't
comply to any kind of metric, and the discussion mostly went down with
that.
So, since I really like to get a release process up and running, let me
a 'minimum viable' proposal here:
Let's decide on a schedule and create releases, with only minimal
testing for now.
There's no support and no guarantees which things work (before you
scream, see below).
The main goal is to learn how to do releases, and go from there.
From my point of view, a release entails the following:
- a timeline (for now, an announcement akin to 'next release will be on
february 32th')
- a git tag
- a tarball that contains that tree state
- release notes and changelog (a bit more than just git log)
For the first few releases, until we broaden the scope, those release
notes need to be very clear about the nature of these releases (and that
they are merely code dumps, not tested pieces of engineering).
From there, we could set ourselves goals, for example 'by the release
date the board(s) I maintain work with a commit that is at most a week
old, and I'll provide board-status reports with the released version'.
This provides us with a record of what happened between two points in
time. It provides goalposts to attach goals to. And we're building
experience with what kind of 'things work' guarantees are actually
realistic for us and which aren't.
From there we can discuss further ways to make use of those goalposts
(including dropping boards or chipsets, at some point). Or drop the
release concept if all that turns out not to be worthwhile - but with
the knowledge why it isn't.
Thoughts?
Patrick
