coreboot

coreboot@coreboot.org

6 participants
39707 discussions

Re:Loading OS from Flash ROM!
by John Praveen 24 Jul '03

24 Jul '03

On Fri, 18 Jul 2003, John Praveen wrote: > I am new to linux bios. My project is based on > geode chip. I want my linux OS to be in Flash ROM(capacity 4 MB). >I have sad news. You can't get a 4 MB chip on that board, I bet. I can't get to this. This means that 4 MB Flash ROM cannot be used with SC1200? Or is it not supported in LinuxBIOS. Plz help me to understand these. >It is >probably 4 Mbits, 512 KB. You'll have to put that overweight linux kernel >on a diet to get it to fit in there. >One option is 2.4.0 or so, that might fit. >Can DoC fit on your geode anywhere? No I don't use DiskOnChip. Thanks. --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!

3 8

irq routing on TigerMPX.
by Oleg Gusev 24 Jul '03

24 Jul '03

It seems that linuxbios (and linux) uses the irq routing tables dumped from the bios mptable. Are there any good reasons to reroute 9 pci/agp interrupts (2 64-bit slots on the first pci bus + 1 agp + 4 32-bit slots + builtin ethernet on the second pci bus) to 4 apic pins 16,17,18,19 when at least the pins 5,9,10,11 are not used at all ? Now i have 3 devices sharing pin 19, and 2 devices on 16,17 and 18. Is this the intended use of io-apic ? Oleg.

2 1

DoC again
by Martin Schmachtel 23 Jul '03

23 Jul '03

These may sound like stupid questions to you, but please bear with me, I'm new to this stuff and have not found anything definitive on google about it. M-Systems apparently no longer produces the Disk-on-chip millenium with the part number MD-2800-D08. The successor MD-2802-D08 is supposed to be compatible , but I'd like to be a little more certain about it. Has anybody used the new chips with linuxbios successfully? Can any bios chip (in DIP-32 package) be replaced by a DoC? Or are there any requirements not all boards fullfil, like not all needed address lines are connected? More specifically, I'd like to try to get linuxbios working on my Asus P2B, which I hope will not be too difficult since some support for 440BX seems already present. ciaole schmadde

3 2

OT: job offer
by Franz Reinhardt 23 Jul '03

23 Jul '03

wenglor sensoric gmbh sucht: PC-HW/SW-Entwickler (Ingenieur/Techniker mit Berufserfahrung) zur Schaltungsentwicklung und Treiberprogrammierung. Anforderung: Fundierte Kenntnisse in der PC-Architektur Aufgabengebiet: Entwicklung von PC-basierten Hauptplatinen Schaltungen in der PC-Peripherie (z.B. PCI-Bus) Mit über 300 Mitarbeitern sind wir in Deutschland die Nr. 2 im Bereich der optischen Sensorik. Informationen zur Firma und unserer Produktpalette entnehmen sie bitte unserer Homepage http://www.wenglor.de Weitere Informationen zu diesem Stellenangebot erhalten sie per Email: fre(a)wenglor.de oder telefonisch: +49 (0)7542-5399-421 -- ----wenglor(R)----sensors for your success----------

3 2

TigerMPX and s2466.
by Oleg Gusev 23 Jul '03

23 Jul '03

Is there any difference between these two mainboards, other than s2466-4M having 4Mbit flash ROM? I would like to test linuxbios, but it is not obvious which one to take. Oleg.

1 0

freebios2 mod to reset code.
by ron minnich 23 Jul '03

23 Jul '03

Now that we are using romcc, and all functions are inline, it is getting increasingly painful to deal with linuxbios images smaller than 64k. This problem happens as we need a 16-bit jump to the start of the linuxbios code, which limits us to jumping to 0xffff0000. But if linuxbios is bigger than that, we need to be able to jmp to 0xfffe0000, which is not possible with the current setup. We can grow this if we do the following: make reset a rel jump to 0xfffffff0 - (sizeof entry16). Then put entry 16 right before 0xfffffff0. Entry16 code turns on 32-bit mode and then jumps to the real start of the linuxbios image -- which can now be anywhere in the flash image. I could use this now, as could others. here is sample code which I am trying. It now assembles and inspection of the object reveals that it is certainly close to correct. Here's where I wish I had a really good emulator for linux -- checking this out would be a whole lot easier. The test reset16 code: .section .reset .code16 .globl rgdtptr16 .globl reset_start .type reset_start, @function reset_start: cli xorl %eax, %eax movl %eax, %cr3 /* Invalidate TLB*/ invd movw %cs, %ax shlw $4, %ax movw $gdtptr16_offset, %bx subw %ax, %bx data32 lgdt %cs:(%bx) movl %cr0, %eax andl $0x7FFAFFD1, %eax /* PG,AM,WP,NE,TS,EM,MP = 0 */ orl $0x60000001, %eax /* CD, NW, PE = 1 */ movl %eax, %cr0 /* Now that we are in protected mode jump to a 32 bit code segment. */ data32 ljmp $ROM_CODE_SEG, $__protected_start /** The gdt has a 4 Gb code segment at 0x10, and a 4 GB data segment * at 0x18; these are Linux-compatible. */ .align 4 .globl rgdtptr16 rgdtptr16: .word gdt_end - gdt -1 /* compute the table limit */ .long gdt /* we know the offset */ .globl reset_vector .align 4 reset_vector: jmp reset_start The net effect is this: 16-bit reset jmps to a very small startup code right before 0xfffffff0 that enables full 32-bit mode. We can then jmp anywhere we want -- to 0xfffe0000 for example -- which we can't do now. This will alleviate the problem of linuxbios images growing to > 64K which is a consequence of romcc right now. This will allow us to live with really big linuxbios images until romcc makes tighter code. Comments? Errors in the code? thanks ron

3 12

Re: K8 + 2.4.21 + Tyan S2880
by YhLu 23 Jul '03

23 Jul '03

Eric or Ron or Stepfan, To make the NIC under mem auto-conf code, I have spent one day on it. Here are my findings: 1. Use the most updated code, in the Etherboot stage it will reboot after firt NIC try aborting. 2. I have try to subsutite mem-conf with hard code version, and found another problem, I can not start AP after conherent_ht or memory initization. Only can start and stop in enable_routing function. 3. I have to move back to old code ( Before Eric moved some definition from romcc_io.h to arch/io.h and cpu/p6/msr.h). At this situation, if I use mem-conf, it still can not find broadcom nic in etherboot stage. But after I substitute mem init with hard code one, It can find the nic. I will study the difference today. But anyway what make I can not start AP after conherent_ht or memory init, so strange ??? Regards Yinghai Lu -----邮件原件----- 发件人: YhLu 发送时间: 2003年7月22日 10:41 收件人: 'ebiederman(a)lnxi.com' 抄送: ron minnich; Stefan Reinauer; linuxbios(a)clustermatic.org 主题: Re: K8 + 2.4.21 + Tyan S2880 Eric, It can be compiled with you new code. But it meet problems in Etherboot stage. In S2880 has two broadcom NIC port in 8131 bus B, and one amd 8111 built-in nic, and even if I hide it in amd8111 init and Etherboot can find it and try to enable it and can not find the PM cap so aborting, in the old linuxbios code (before yesterday) ( with mem hard code), it will go to tickle on Broadcom nic, but in the new code (yesterday check in) ( mem configurable), it will go to MB restarting.??? How about arima broadcom nic position? Regards Yinghai Lu -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2003年7月21日 18:33 收件人: YhLu 抄送: ron minnich; Stefan Reinauer; linuxbios(a)clustermatic.org 主题: Re: K8 + 2.4.21 + Tyan S2880 YhLu <YhLu(a)tyan.com> writes: > Eric, > > In the auto.c, if I enable : sdram_initialize(&cpu1), the linuxbios need > another 20k. What happened? Only add one line and the same function has been > called ??? All functions are inline and the set of functions called is large. At least I believe that is the issue. And good luck catching up.... While I am away you get a chance. My latest code has changed sdram_initialize one more time to take a cpu count parameter. And perversely this should help because if a function is called in a loop it will only be inlined once instead of multiple times. Eric

1 0

static and dynamic devices (again)
by ron minnich 23 Jul '03

23 Jul '03

Greg has spent the day exploring options for how to merge the static and dynamic device trees in LinuxBIOS, per Eric's comments. He wrote a substantial amount of code, which at this point we may not commit. The goal of the code was to see if it makes sense to merge the static and dynamic trees. I am not convinced such a merger makes sense. Discussion follows. The problem is this: on a given motherboard, there are a static set of devices, such as northbridges, southbridges, so on: these are soldered to the board. Then there are dynamic devices, plugged into PCI slots. On a motherboard, we know that the static devices are there, and we even know a lot about them, such as what certain registers do. We need on the motherboard to initialize components of the static devices. In other words, we have knowledge about: o the type of the device; o instances ofthe device; o special operations we need to do to the device to modify internal state (e.g. turn off the IDE controller, turn on Ethernet, etc.) o special control information that is highly device-specific These operations are operations that we have to do because the OS assumes they will be finished when the OS starts, or we need to do them to initialize things, such as DRAM. Dynamic devices are known only in a generic fashion. In LinuxBIOS, the sum total of our knowledge of dynamic devices is the Base Address Register set, the Command register, and possibly (in future) the IRQ. LinuxBIOS has no knowledge of device-specific I/O registers. For dynamic devices, LinuxBIOS does a few generic operations and lets the OS do the rest. So for dynamic devics we know about: o instances of the device o Generic control information that is not device-specific So, to sum up: for static devices, LinuxBIOS needs knowledge that goes beyond what the OS knows, and will perform device-specific operations based on internal knowledge LinuxBIOS has about the device. LinuxBIOS will maintain information about the type of the device and all instances of the device. In many cases, LinuxBIOS will do operations on the device that the OS is not capable of doing. For dynamic devices, LinuxBIOS only does the most general configuration, and has no knowledge of device internals. The OS manages device-specific operations. The dichotomy is pretty clear. It is kind of like a house. There are walls and floors and outlets and phone jacks. These are fixed (static). Then there are chairs and lights and phones. These are dynamic. You know all about the phone jacks, but you don't know about what phones are plugged in, and the phones change all the time, especially if you have children in the house. The static devices (walls) are a fundamentally different thing than the dynamic devices (chairs). We are calling static devices 'chips'. Chips are structured as follows: there is a chip_control structure for a TYPE of a chip, with generic information about the chip and a pointer to a control function that is specific to that chip. Then, for each instance of the chip, there is a chip structure that contains a pointer to the chip_control structure and information specific to the INSTANCE of the chip. Think of chip_info as the class definition, and chip as instantiations of the chip. Chips are statically declared and initialized, and form a tree with a root at the mainboard, with sibling pointers for chips at the same level -- e.g., two devices hung off the same southbridge are siblings. These structures are filled out at compile time. Dynamic devices are called struct device. There is (currently) a device struct allocated dynamically for each function on a device. [digression: The PCI heritage of devices is very clear once you start looking at them. This is reasonable, as even on HyperTransport everything looks like a PCI device. But it may bite us at some point.] Devices also form a tree, with children, parents, siblings, etc. One assumption we've noticed in the device code is that of a 'root bus'. Properly, this should not really exist: there can be multiple northbridges in a system, each with a PCI bus. But the device code so far inherits from freebios 1.0 the PC assumption that there is one root bus, and that it is configured from a common point of control -- on PCs, the 0xcf8/0xcfc mechanism. Our early assumption was that we could take the static tree, build a dynamic tree, and then populate the tree with dynamic devices. Eric would like to see this happen. Greg and I are no longer convinced this makes sense. Hence the source of this discussion. At minimum, if you build a dynamic tree from the static tree, you'll have to mark the devices as static. You'll have to handle them differently because the resources work differently. Some resources such as Base Address Registers won't exist on devices in the static tree. You'll have to note that some devices are capable of having device-specific code, and others are not. You'll end up with structure that really contains two structures inside: structure members for static devices only, and structure members for dynamic devices only. It won't be a happy marriage. Finally, all your code will have to handle two cases: static and dynamic devices. Once we looked at this, we saw that we ended up with a dynamic tree with static devices grafted in, with no apparent savings on complexity and no real code reuse. Here is what we think makes sense. The dichotomy between static and dynamic devices should remain. The static devices will not be converted into some form of dynamic device. There will need to be a linkage from the static devices to dynamic devices. This linkage will be at the northbridge -- as it is in hardware. Northbridges, i.e. devices which have an attached PCI bus (or more than one), will have a device structure pointer in the device-specific data structure (i.e. in the chip structure). At some point, as part of the code that walks the statically allocated northbridge, pci enumeration for that northbridge takes place. This has a major advantage for non-PC platforms (such as PPC) that don't use the standard PC 0xfcf8/0xcfc mechanism for configuring the PCI bus -- it makes sense to talk to the northbridge device directly to configure the bus(ses) on that northbridge. It is also a big win for systems with more than one northbridge -- these will be more and more common. And for switched, not bus-based, systems the advantage is apparent. We thus have a static tree (representing the static resources) with links at certain places to the dynamic tree (representing dynamic resources). LinuxBIOS can do device-specific operations on devices in the static tree, and can attach dynamic devices to nodes in the static tree. On the whiteboard in Greg's office, this setup makes lots of sense. We'll see how it is in practice. We plan to prototype this in the coming few days and try it out. Comments and questions are welcome. We need to open this discussion up. I would really like to hear from you folks. As Eric pointed out, we're trying to define the 2.0 core functionality, and we want to make it a good structure but also one that is easy for people to do new ports. It is essential to hear from those of you who are doing ports -- there are lots of you on this list. thanks ron

4 4

alternate startup idea.
by ron minnich 23 Jul '03

23 Jul '03

Well, my alternate startup idea works fine on the K8. Except ... looks like flash rom addressing is not enabled by default for anything but the 0xffff0000 segment, which means while my idea works, it's useless: if I jump to the 0xfffe0000 segment, I'll be reading air, not the flash part. Darn it. I kind of wish that we could get the chipmakers to default to full addressing in the high part of the address space, i.e. when it decodes for the flash, it decodes from 0xfff00000 up, not 0xffff0000 up. Someday ... Well, at least I have an interesting (I guess) proof-of-concept. Not sure where to take it, but I think I'll go ahead and put it aside. Sigh. ron

2 2

NVidia NForce2
by Marco Hetzel 23 Jul '03

23 Jul '03

Hi! The help-fromular on your page isn't working, so I once again try to write here. Are there any Driver for the NForce2 - Chipset? THX, Marco

1 0

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