?
Best Regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
ose are IO ports and have nothing to do with
memory addresses?
Best regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
appening.
Best regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Juhana Helovuo wrote:
Oh, this was very good! Thank you! Now I can load Linux kernel on the
M4A78-EM, although it doesn't boot successfully yet.
[...]
I'll have to do some more testing to find out more.
More testing done, and now Linux boots to login prompt.
I regenerated irq_tab
003000-3fff: RESERVED
5. e000-efff: RESERVED
Wrote coreboot table at: 2fffe000 - 2fffe1bc checksum ba50
But does it really matter? There is now physical RAM only up to
4000. Or is it going to be a problem if there is more than 3 GB RAM?
Best regards,
Juh
just by plugging in another chip. Has anyone tried this?
Best regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
mmconf patch you sent to this
list on 2nd December commited to SVN. That should create a trunk
revision, which is usable on this board without any source patching.
Best regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
on Qemu with only
Coreboot + VGA BIOS and Memtest86+ directly as payload.
If anyone cares to test this on their hardware, please report if this
works for you.
Best regards,
Juhana Helovuo
diff -Naur memtest86+-4.10.renamed/coreboot.c memtest86+-4.10.j/coreboot.c
--- memtest86+-4.10.renamed
Carl-Daniel Hailfinger wrote:
On 05.12.2010 12:26, Juhana Helovuo wrote:
How does a chipset know the size of the SPI BIOS ROM on board
Chipsets do not know the size of the flash ROM chip.
Ok. Thanks for the explanation, Carl-Daniel and Rudolf.
I tried substituting a bigger SPI ROM chip on
original BIOS chip safe, so that you don't
accidentally flash over it. The safest thing should be to first practice
with flashrom by reading the original BIOS image, then replacing the
BIOS chip with a new one while the board is running, and then flashing
the factory BIOS to the new chip
serprog", mainly by
adapting it to suit SPI.
Best regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
1.2.2011 14:58, Peter Stuge kirjoitti:
Juhana Helovuo wrote:
unit that can administer testing of one or even better several
mainboards. I have plenty of design and implementation ideas if
you'd like to go into that.
I started building a tester device to hook up a mainboard into an
auto
! I suppose git would do better for this job, since I expect
that the development is quite decentralized. Right now I have only the
prototype board schematics and layout, but I suppose that is already
better than nothing. Do have a good home for a git repository available?
Best regards,
Peter Stuge wrote:
Juhana Helovuo wrote:
Here are some images of my first (incomplete) prototype:
http://alpskari.asiantuntijat.org/~juhe/spi-flasher-piirilevyt/
Looks like a great start!
Now there is more progress. After some building, coding, and debugging I
have the tester sort-of
e USB controller.
Best regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
, including default control
endpoint. Maximum packet size is 64 bytes. Two of the endpoints can be
double buffered in hardware.
Is this enough details, or do you need something else?
Best regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman
d vs. manually coded?
Best regards,
Juhana Helovuo
$ lspci -tvnn
> -[:00]-+-00.0 Advanced Micro Devices [AMD] RS780 Host Bridge Alternate
> [1022:9601]
>+-01.0-[:01]--+-05.0 ATI Technologies Inc Device [1002:9710]
>| \-05.1 ATI Technol
Juhana Helovuo kirjoitti:
Hello,
I am trying to get coreboot working on Asus M4A785-M with Athlon II X2
240e CPU (Socket AM3). So far there is no success.
Hello again,
There is now some progress in this port.
- Found out that the northbridge was wrong. We should use AMD Family 10
instead
same devices many times.
Best regards,
Juhana Helovuo
coreboot-4.0-r5631M Thu Jun 17 06:40:35 EEST 2010 starting...
BSP Family_Model: 00100f62
*sysinfo range: [000cc000,000cdfa0]
bsp_apicid
On Wed, 2010-06-16 at 14:04 -0600, Myles Watson wrote:
> On Wed, Jun 16, 2010 at 1:55 PM, Juhana Helovuo wrote:
> > On Wed, 2010-06-16 at 08:30 -0600, Myles Watson wrote:
> >> > Coreboot now boots past the romstage and starts setting up PCI devices.
> >> > Unfort
2:1203]
\-18.4 Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64,
Sempron] Link Control [1022:1204]
So it seems that something goes wrong inside isa_dma_init();
Now I am not sure what I could try next. As the LPC is needed for Super
I/O access, it seems like it cannot be just lef
On Thu, 2010-07-29 at 20:14 +0300, Andriy Gapon wrote:
> Juhana Helovuo said the following:
> > Meanwhile, I added call to it8712f_kill_watchdog() , like Rudolf Marek
> > suggested.
>
> BTW, if it's not too hard, could you please share what value that register
> (IT8
- 0x7fff is reserved as
"iomem" to device "pnp 00:01".
Now the next step would be to get Linux to accept the ACPI tables, but I
do not really know where to begin debugging them.
Best Regards,
Juhana Helovuo
[0.00] Initializing cgroup subsys cpuset
[0.00]
r where and how all of these memory maps are
transmitted from Coreboot to Linux. I could not find the callback for
BIOS e820 calls in Coreboot sources.
Best regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
the SeaBIOS "home page".
So far I have Grub2 more or less working, so is Coreinfo, and I can also
get response (VGA & keyboard) from FILO, although it does not find my
disks. Grub2 sees my IDE disk and cdrom as "ata6" and "ata7".
Best Regards,
Juhana Helovuo
contribute a patch for this mainboard to the
Coreboot project, but first I have to clean the code I have mangled back
and forth.
Best Regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
before
coreboot tables, but it seemed to cause no harm for me.
Signed-off-by: Juhana Helovuo
Best regards,
Juhana Helovuo
diff -u -r -N -x .svn coreboot.orig.r5756/src/arch/i386/boot/multiboot.c coreboot.r5756/src/arch/i386/boot/multiboot.c
--- coreboot.orig.r5756/src/arch/i386/boot/multiboot.c
Patrick Georgi kirjoitti:
Am 30.08.2010 20:54, schrieb Juhana Helovuo:
Hello,
The attached patch adds all the memory memory ranges in the coreboot
tables also to the multiboot tables. It is useful e.g. when booting
Linux with Grub2 payload, since then Linux gets the Coreboot memory map
via
On Mon, 2010-08-30 at 21:46 +0200, Patrick Georgi wrote:
> Am 30.08.2010 20:54, schrieb Juhana Helovuo:
> > Hello,
> >
> > The attached patch adds all the memory memory ranges in the coreboot
> > tables also to the multiboot tables. It is useful e.g. when booting
&
does SeaBIOS detect which RAM is usable and which is not? Maybe the
memory conflict with UMA and ACPI tables could be avoided in a similar
manner?
Best regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
to prevent hangups/crashes on this board.
(3) Multiboot table patch required to get UMA and high coreboot tables
locations to Grub and Linux. Independent of (1) and (2).
Signed-off-by: Juhana Helovuo
I tested appying these patches, building and flashing using the
following procedure:
1.
s could be smaller and neater.
However, I cannot hold on to this board for arbitrarily long, since I
should put it to production use now that Coreboot is working. I will
see what I can do to reduce these patches further, if I just find a
suitable slot of time.
Best regards,
Juhana Helovuo
-
rivers failing, the boot logs seem to be the
same as before.
I tried to look at the patch code, but could not figure out why this is
happening.
Best regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
o narrow down where the failure is. The first
thing to check would be to see if the cause was in different patches
(original vs. simplified) or trunk code (5792 vs. 5799).
Then I'll see what uma.diff and reserved.diff do.
Best regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@
On Sat, 2010-09-11 at 23:36 +0300, Juhana Helovuo wrote:
> On Sat, 2010-09-11 at 07:03 -0600, Myles Watson wrote:
>
> > So it works with my updated patch, but not with the uma & reserved
> > patches? Or does it not work at all? Does it still work with your
> > previo
e other hardwiring?
Since variable "msr" here is local to the routine, I don't see how it
could have effect on anything else but the UMA location and size. The
value read from TOP_MEM2 isn't even used for anything but printing.
Best regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
correct? If yes, then the northbridge is creating holes
into RAM, in order to have PCI memory-mapped IO in 32-bit addresses.
Now, if I wish to have Coreboot to cope with large memory and holes,
what manuals do I need to understand and modify the codes managing this?
Best regards,
Juhana Helovuo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
t; is multiboot-compatible ELF executable and "memtest.bin" is
bootable image like a Linux kernel image. Choosing between these two
depends on your boot method: BIOS, Coreboot only, Coreboot+SeaBIOS, or a
bootloader.
My success with memtest86+ has been rather limited, but maybe this works
38 matches
Mail list logo