Re: Error in compiling STPC Consumer
On Thu, 24 Mar 2005 05:54:17 + (GMT), Ramesh Chhaba [EMAIL PROTECTED] wrote: Yes Sir , u was right that I was missing that payload = line in configuration :) So I have aded that line and also enabled STD_FLASH and ELF_BOOT options and also added PAY_LOAD_SIZE = 64KB and ROM_SIZE =126KB But I want to make my romimage within 256KB So what options I acn change to do that currently my image is 356 (approx) KB PAY_LOAD_SIZE is not a maximum size. its the blocksize option thats used in the 'dd' statemnet that copies the payload into a file. So 64k is the minimum it will be but it could be 128k, 192k, 256k, etc. Make your ROM_SIZE be the size you want the image - payload size. You can see all the magic for this in the makefile that the config tool generates. I remember I had to tweak with my numbers till I got to to come out the right size. 356k seems a little large for just linubios and etherboot. How big is your payload? -- Richard A. Smith ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Notebook 340s2 (sis630) 256k Flash
On Wed, 23 Mar 2005, Bari Ari wrote: yes, that's right, I found it when I dissassembled the whole notebook right now. (Beside is a PC87570, a Keyboard and Power Controller. http://www.national.com/pf/PC/PC87570.html) Just hope they didn't route the Flash write through the 87570. The micro has 2KB or ROM so you can't change that if it's been burned in. Does that mean something like if I rewrite the Flash, a Part of the old Bios is still in the ROM of the 87570. The modified code in flash will never be able to work? How can I test this, is there any way? Norbert ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Notebook 340s2 (sis630) 256k Flash
Just hope they didn't route the Flash write through the 87570. The micro has 2KB or ROM so you can't change that if it's been burned in. Does that mean something like if I rewrite the Flash, a Part of the old Bios is still in the ROM of the 87570. The modified code in flash will never be able to work? It means that the 87570 may have control of the write enable line on the flash. If its not asserted no writes to the flash will be possible unless you pull the chip. Figureing out whats involved in allowing the write line to be enabled usually requires snooping on the IO ports while the factory re-flash routine runs. Note: thats not the same as disassembling the factory re-flash code which could taint linuxbios with copyrighted code. How can I test this, is there any way? If you have access to a oscope then you can watch the write enable and the chip enable lines while running the linuxbios flash routine they must both be asserted at the time you try to write to the flash. If you are software only then boot bochs on the machine and enable IO logging then run the factory re-flash. If it does a buch of port IO to the 87570 prior to starting to program then WE has a good chance of being under its control and you will have to duplicate that IO prior to and/or while running the linuxbios reflash. -- Richard A. Smith ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Error in compiling STPC Consumer
On Thu, 24 Mar 2005, Richard Smith wrote: On Thu, 24 Mar 2005 05:54:17 + (GMT), Ramesh Chhaba [EMAIL PROTECTED] wrote: Yes Sir , u was right that I was missing that payload = line in configuration :) So I have aded that line and also enabled STD_FLASH and ELF_BOOT options and also added PAY_LOAD_SIZE = 64KB and ROM_SIZE =126KB But I want to make my romimage within 256KB So what options I acn change to do that currently my image is 356 (approx) KB PAY_LOAD_SIZE is not a maximum size. its the blocksize option thats used in the 'dd' statemnet that copies the payload into a file. So 64k is the minimum it will be but it could be 128k, 192k, 256k, etc. Make your ROM_SIZE be the size you want the image - payload size. You can see all the magic for this in the makefile that the config tool generates. I remember I had to tweak with my numbers till I got to to come out the right size. 356k seems a little large for just linubios and etherboot. How big is your payload? this is a clear FAQ entry. ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Error in compiling STPC Consumer
Second thing I have got the BIOS writer guide for STPC So If I think I changes the replaces the code of STPC_ELITE for that of STPC_ATLAS then I can make it for STPC_ATLAS If you are going to have to do a lot of re-write work I encourage you to start over with V2. V1 is a dead end product and will be very difficult for the linuxbios developers to support you as we are all focusing on V2. V2 is so much nicer to work with compared to V1. In V2 almost everything is in C rather than assembly, even all your RAM init code is C due to Eric's marvelous romcc which is a C compiler designed to use registers rather than RAM. The STPC Atlas is basically a fast cryix 486 so I don't know what impact that has on romcc due to its smaller register set and if its been tested on that arch much but its shouldn't be too much effort to make it work. Right Eric? I'll be happy to help you with V2. We have several boards that use the Atlas here at bitworks and I'd love to see them boot linuxbios rather than what we are using now. However, since what I have now works I don't have much leverage at spending developemnt $$ on replacing it. It would be really nice however to be able to boot from IDE CD-ROM or USB which is something our current BIOS can't do. But I have systems that I can test on and help you get V2 up and going. -- Richard A. Smith ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Error in compiling STPC Consumer
this is a clear FAQ entry. For v1 yes but not for v2 and most of our docs now are all for v2. I think I would still make v1 people ask so we can tell them not to use v1. -- Richard A. Smith ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Error in compiling STPC Consumer
On Thu, 24 Mar 2005, Richard Smith wrote: think I would still make v1 people ask so we can tell them not to use v1. ah, good point. Hey richard, previous letter, question is: Q. Should I use V1? A. Your previous letter ron ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Error in compiling STPC Consumer
Richard Smith [EMAIL PROTECTED] writes: Second thing I have got the BIOS writer guide for STPC So If I think I changes the replaces the code of STPC_ELITE for that of STPC_ATLAS then I can make it for STPC_ATLAS If you are going to have to do a lot of re-write work I encourage you to start over with V2. V1 is a dead end product and will be very difficult for the linuxbios developers to support you as we are all focusing on V2. V2 is so much nicer to work with compared to V1. In V2 almost everything is in C rather than assembly, even all your RAM init code is C due to Eric's marvelous romcc which is a C compiler designed to use registers rather than RAM. Right. V1 is essentially frozen so nothing that used to work breaks. The very nice thing about V2 that the structure of the code makes it much easier to write reusable code. The STPC Atlas is basically a fast cryix 486 so I don't know what impact that has on romcc due to its smaller register set and if its been tested on that arch much but its shouldn't be too much effort to make it work. Right Eric? All you have to do is not tell romcc it has mmx or sse registers. For a modern memory controller that gets awfully tight but for a simpler memory controller it should be doable, to make everything fit. I almost had the Opteron memory controller working in just 8 registers. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Notebook 340s2 (sis630) 256k Flash
The PC87570 has some code in ROM and it also shares the Flash BIOS memory with the PC host. Page 49 of the http://www.national.com/ds/PC/PC87570.pdf datasheet has the info on this. If you rewrite the entire Flash you may erase the portion (up to 56K for code and data) of the BIOS for the PC87570 that will be in CR16A (NSC RISC) format vs. the x86 portion of the BIOS. The Keyboard and Power Management Controllers are the non-standard parts of laptops and one reason why there hasn't been LinuxBIOS support for one yet. A laptop with LinuxBIOS support can easily be designed. Getting LinuxBIOS support for an existing design is lots of work if you have to reverse engineer without OEM schematics and docs. -Bari Norbert Schmidt wrote: On Wed, 23 Mar 2005, Bari Ari wrote: yes, that's right, I found it when I dissassembled the whole notebook right now. (Beside is a PC87570, a Keyboard and Power Controller. http://www.national.com/pf/PC/PC87570.html) Just hope they didn't route the Flash write through the 87570. The micro has 2KB or ROM so you can't change that if it's been burned in. Does that mean something like if I rewrite the Flash, a Part of the old Bios is still in the ROM of the 87570. The modified code in flash will never be able to work? How can I test this, is there any way? ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
