coreboot

coreboot@coreboot.org

10 participants
39710 discussions

DDR Bank1 is ont working on VT8623 northbrodge
by Jia Jianwei 25 Nov '03

25 Nov '03

I use the code of VT8623 to active DDR RAM, but only BANK 0 is working, BANK 1 is not working.If I only use BANK0 or BANK1, it is working well. I tried to active it twice with only one bank setting, yes , It's working with memtest, but, PCI burst does not work, All PCI bus master device do not work. Anybody can tell me Why? Best Regards, Jianwei

1 0

Re: Tyan S4880
by YhLu 25 Nov '03

25 Nov '03

Thanks, Stefan, After I change MAXIMUM_CONSOLE_LOGLEVEL from 9 to 8 it works. YH. -----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2003年11月25日 1:54 收件人: YhLu 抄送: Eric W. Biederman; linuxbios(a)clustermatic.org 主题: Re: Tyan S4880 * YhLu <YhLu(a)tyan.com> [031125 03:37]: > Stefan, > > I'm porting Tyan S4880 now. I found that the following building err, do you > meet it in AMD board? No, the AMD boards build fine for me. gcc-3.3.1-29 binutils-2.14.90.0.6-8 > Even I only enable the CPU0's memctrl in the auto.c It seems the struct itself in auto.c is pretty uncritical for size. Other parts like the log level need a lot more tuning if you want the image to be as verbose as possible. * Do you compile with romcc -O (not -O0 and not -O2) * What's your max log level? The UP-build (Solo) allows me to put MAXIMUM_CONSOLE_LOGLEVEL up to 10, other builds want less. > objcopy -O binary linuxbios linuxbios.strip > gcc -o buildrom /home/yhlu/xx/xx/freebios2/util/buildrom/buildrom.c > ./buildrom linuxbios.strip linuxbios.rom ../../tg3.zelf 0x10000 0x18000 > linuxbios image is 65854 bytes; only 65536 allowed > Linuxbios input file larger than allowed size! Is this 64k including payload size? I use: option ROM_SIZE=262144 option FALLBACK_SIZE=131072 option ROM_IMAGE_SIZE=0x10000 guess the size issue should be mentioned in the docs. Everybody fiddling with LinuxBIOS on AMD64 _has_ seen it.. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development

1 0

RE: Off topic CF questions
by Alan Mimms 25 Nov '03

25 Nov '03

We have information from a Compact Flash manufacturer that says you should have hardware to solve this problem - I do not believe there is a software solution. The problem is caused by the fact (as you state) that CF stores metadata in the flash blocks along with the disk block data. If the metadata is corrupted by an aborted write, it can affect all of the disk blocks stored in the flash block, and the metadata can even be so corrupt that you lose unrelated blocks. Our most common scenario for failure is to lose disk block #0, which, of course, is the boot block for our OS. We solve this using hardware. You need to use buffers to disconnect the CF's ATA reset, output-enable and write-enable signals from their source on the bus, and hold up DC power to the pull-ups, the buffers and the CF itself for at least 10ms-20ms after detecting the imminent loss of power. This is being implemented in our new hardware designs, and we have not yet gotten one back from fabrication to test. But it sure looks like it will work to solve the problem. Alan Mimms, Senior Architect F5 Networks, Inc. Spokane Development Center Liberty Lake, Washington v: 509-343-3524 f: 509-343-3501 -----Original Message----- From: linuxbios-admin(a)clustermatic.org [mailto:linuxbios-admin@clustermatic.org] On Behalf Of tyson(a)irobot.com Sent: Monday, November 24, 2003 4:47 PM To: LinuxBIOS Subject: Off topic CF questions This is a bit off topic, but I need some pointers and we seem to have quite a few really smart people on this list. ;-) I'm trying to learn about the issues and solutions to using CF cards for data logging in appliances where the power may be pulled at any time. There are sort of two classes of logging. One would be classic "write only" logging. The other would be things like total run time, an odometer, that sort of thing where you might want to something that amounts to erase the old value and over write it with a new one. Obviously the second case would degenerate a bit with at least "double buffering" and could get as "bad" as a "write only" log history. I say write only, meaning that the download/reset/erase procedure could be under controlled conditions and not a concern. My issue is that CF cards present and IDE abstraction that hides the underlying block sizes and the fact that FLASH is erased as a block (and unknown block) and rewritten from scratch. I have absolutely no idea what size these blocks are such that I might separate my "read-only" partitions from my "write only" partitions with a buffer partition. I also have absolutely no idea what happens to these things when the power is pulled, esp. in the middle of an erase/write cycle or how these erase/write cycles might be optimised. Any pointers or suggestions would be greatly appreciated. Thanks! Ty -- Tyson D Sawyer iRobot Corporation Senior Systems Engineer Military Systems Division tsawyer(a)irobot.com Robots for the Real World 603-654-3400 ext 206 http://www.irobot.com _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

V2 dependency problems
by Dave Ashley 25 Nov '03

25 Nov '03

The auto.c file has #includes for things like raminit.c. If I change the auto.c file and rebuild, the changes "take". If I change raminit.c, the changes don't take. I have to touch the auto.c to get it to work. Does everyone have this problem? I do cd targets ; ./buildtarget via/epiam (Above done only once) Then to rebuild make -C via/epiam/epiam One other note that I kind of recall being discussed. I cloned the vt8231 directory to make the vt8235 directory, but a lot of the separate pci devices that are inside both devices are identical. Isn't there some way of separating out the support code for the individual components maybe based on the pci device id's? This would avoid code duplication. Like the southbridge/via/vt8231 directory would be the toplevel file that would glue together all the separate components. It would be a list of what individual drivers to include + no redundancy. Maybe there could be another area like components/via/1106-0571 One thing that would be convenient though is devices that are almost exactly the same but have different pci device id's. CVS doesn't like symlinks though. You'd like the handler code to support all equivalent devices. So maybe having the directory name based on the pci id is no good. Maybe instead components/via/ide/id.h components/via/ide/handler.c The id.h file would list the pci device id's the handler supports. Just some thoughts. -Dave PS Sorry if this is a duplicate. The original message didn't seem to work.

2 1

Any one help me!! VIA EPIA MII boot from CF card(PCMCIA) with LinuxBIOS + filo problem
by eddyfu＠pchome.com.tw 25 Nov '03

25 Nov '03

Hi All: How to use VIA EPIA MII to boot from CF card(PCMCIA) with LinuxBIOS + filo problem? Could the LinuxBIOS CVS v1 work on EPIA MII? Best regards, Eddy ========================================================== 升級無線寬頻最後機會 http://edm-prg.epaper.com.tw/click.php?ad_code=36092 ========================================================== PChome交友~~幸福天天有 \*^o^*// http://love.pchome.com.tw/ ==========================================================

2 1

Re: migrate VIA vt5426 to PCChip M787CL(not M787CL+)
by riskin＠esinosoft.com 25 Nov '03

25 Nov '03

After doing test,I find that if linux kernel scans devfn above 0xA0, the chipset locks up. Could somebody please give me advice to fix the bug? riskin >>After I migrated VIA vt5426 to new mainboard(PCChips M787CL,not M787CL+: >> NB is VT8601,SB is VT82C686B),when probing PCI devices,the kernel >> halted.So is there any option in LinuxBIOS need to be configed to avoid >> the kernel halt? But the kernel can work well on PCChips M/B bios. >This is an old bug with the chipset. I think we may still have a patch for >it. If linux scans any devfn above (I think) 0x40, the chipset locks up. >Sorry. >ron

2 1

Off topic CF questions
by tyson＠irobot.com 24 Nov '03

24 Nov '03

This is a bit off topic, but I need some pointers and we seem to have quite a few really smart people on this list. ;-) I'm trying to learn about the issues and solutions to using CF cards for data logging in appliances where the power may be pulled at any time. There are sort of two classes of logging. One would be classic "write only" logging. The other would be things like total run time, an odometer, that sort of thing where you might want to something that amounts to erase the old value and over write it with a new one. Obviously the second case would degenerate a bit with at least "double buffering" and could get as "bad" as a "write only" log history. I say write only, meaning that the download/reset/erase procedure could be under controlled conditions and not a concern. My issue is that CF cards present and IDE abstraction that hides the underlying block sizes and the fact that FLASH is erased as a block (and unknown block) and rewritten from scratch. I have absolutely no idea what size these blocks are such that I might separate my "read-only" partitions from my "write only" partitions with a buffer partition. I also have absolutely no idea what happens to these things when the power is pulled, esp. in the middle of an erase/write cycle or how these erase/write cycles might be optimised. Any pointers or suggestions would be greatly appreciated. Thanks! Ty -- Tyson D Sawyer iRobot Corporation Senior Systems Engineer Military Systems Division tsawyer(a)irobot.com Robots for the Real World 603-654-3400 ext 206 http://www.irobot.com

1 0

beeper on Epia 800
by Mario Ivancic 24 Nov '03

24 Nov '03

Hi ! I would like to use beeper or paralell port for debugging in early stages of IPL for DoC Millennium Plus. My question is how can I enable beeper or parallel port on Epia 800 board? I have VT8231 datasheet, and it seems to me that beeper is enabled by default, but it makes no sound. Best regards, Mario

1 0

linuxbios and 512Kb
by Xavier Pegenaute 24 Nov '03

24 Nov '03

Hi, i'm still trying with 512Kb, and i have this problem when i want to put an elf kernel: ------------------------------------------------------------ Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.2 37:init_bytes() - zkernel_start:0xfff00000 zkernel_mask:0x0000ffff Found ELF candiate at offset 0 Dropping non PT_LOAD segment New segment addr 0x10000 size 0x125e4 offset 0x130 filesize 0x137c (cleaned up) New segment addr 0x10000 size 0x125e4 offset 0x130 filesize 0x137c New segment addr 0x91000 size 0x70 offset 0x14ac filesize 0x0 (cleaned up) New segment addr 0x91000 size 0x70 offset 0x14ac filesize 0x0 New segment addr 0x100000 size 0x700000 offset 0x14ac filesize 0x659da (cleaned up) New segment addr 0x100000 size 0x700000 offset 0x14ac filesize 0x659da Loading Segment: addr: 0x0000000005f70fe8 memsz: 0x00000000000125e4 filesz: 0x000000000000137c Clearing Segment: addr: 0x0000000005f72364 memsz: 0x0000000000011268 Loading Segment: addr: 0x0000000000091000 memsz: 0x0000000000000070 filesz: 0x0000000000000000 Clearing Segment: addr: 0x0000000000091000 memsz: 0x0000000000000070 Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000700000 filesz: 0x00000000000659da Clearing Segment: addr: 0x00000000001659da memsz: 0x000000000069a626 Image checksum: 604a != computed checksum: e8c1 Cannot Load ELF Image ------------------------------------------------------------ If i start it with filo it works perfectly (i don't need copy two times an image of 256, i have ROM_IMAGE=458752). I use to record it the flash utility but doing some dirty techniques (SST39SF040), the checksum if i'm not wrong is not calculated in the flash_rom utility. Some idea ? Xavi. Thanks.

2 1

AMD64 Solo Hang - news
by Stefan Reinauer 24 Nov '03

24 Nov '03

Hi, it seems that the Solo motherboard is the only motherboard tested so far that is based on an Athlon64 instead of Opteron CPUs.. The following code in src/northbridge/amd/amdk8/misc_control.c relies on more than one hypertransport link being available: cmd = pci_read_config32(dev, 0xdc); if((cmd & 0x0000ff00) != 0x02500) { cmd &= 0xffff00ff; cmd |= 0x00002500; pci_write_config32(dev, 0xdc, cmd ); printk_debug("resetting cpu\n"); hard_reset(); } This implicitly changes CPU0 Link1 FIFO Read Pointer Optimization, not taking into regard that LDT1 might not be there. It seems this code should rather check all links to see whether they are connected and optimize _all_ of the connected. Is the CPU reset here really needed for the setting to become active? The BKDG does not state this explicitly ... (Therefore I vote for removing it) Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot