[U-Boot-Users] Changed to get CVS head to build sc520_cdp
Both 0.3.0 and the latest head revision refused to build until I made this patch. Am I misunderstanding something?
diff -ru u-boot-0.3.0/include/asm-i386/u-boot.h ../coastal/uboot/u-boot-0.3.0/include/asm-i386/u-boot.h --- u-boot-0.3.0/include/asm-i386/u-boot.h Sun Nov 17 15:11:13 2002 +++ ../coastal/uboot/u-boot-0.3.0/include/asm-i386/u-boot.h Tue May 6 00:44:33 2003 @@ -44,6 +44,8 @@ unsigned long bi_intfreq; /* Internal Freq, in MHz */ unsigned long bi_busfreq; /* Bus Freq, in MHz */ unsigned long bi_baudrate; /* Console Baudrate */ + /* *** added to get the code to compile for x86 */ + unsigned long bi_boot_params; /* where this board expects params */ struct environment_s *bi_env; struct /* RAM configuration */ {
My method was simple.
make sc520_cdp_config make
########################################
On another track, I suspect that there may be a typographically generated bug in cpu/i386/start16.S. The code reads like this.
/* Turn of cache (this might require a 486-class CPU) */ movl %cr0, %eax orl $060000000,%eax movl %eax, %cr0 wbinvd
I believe that the correct immediate value is $0x60000000. The given octal value is 0x00c00000 hexadecimal. According to the Intel documentation I have on hand, these bits are presently reserved in %cr0.
On 2003.05.23 02:50 Marc Singer wrote:
Both 0.3.0 and the latest head revision refused to build until I made this patch. Am I misunderstanding something?
No this problem exists due to changes in the core U-boot parts, not yet reflected in the version of the 386 port which is in cvs and 0.3.0. I am working with Wolfgang to merge a newer version of the 386 port.
My method was simple.
make sc520_cdp_config make
Yes, this is the way.
########################################
On another track, I suspect that there may be a typographically generated bug in cpu/i386/start16.S. The code reads like this.
/* Turn of cache (this might require a 486-class CPU) */ movl %cr0, %eax orl $060000000,%eax movl %eax, %cr0 wbinvd
I believe that the correct immediate value is $0x60000000. The given octal value is 0x00c00000 hexadecimal. According to the Intel documentation I have on hand, these bits are presently reserved in %cr0.
Yes, you are right, of cause. I expect that there are more of this kind of silliness in the i386 port since I still find the my self occasionally.
Best Regards, /Daniel
--
participants (2)
-
Daniel Engström -
Marc Singer