OpenBSD trên bộ xử lý Motorola 88000
OpenBSD on Motorola 88000 Processors
OpenBSD vừa được port lên kiến trúc RISC Motorola 88000 (m88k) – một dòng chip đã khá "lãng quên", ra đời trước cả PowerPC. Việc port này cho thấy thiết kế đa xử lý (multiprocessor-friendly) rất độc đáo của m88k: các đơn vị quản lý bộ nhớ và đồng bộ cache (CMMUs) giao tiếp trực tiếp trên một bus chung, giúp đơn giản hóa việc xử lý giữa các CPU. Các developer có thể học hỏi từ công sức này về cách hỗ trợ các kiến trúc ít phổ biến. Đồng thời, chúng ta có thể thấy cách những thiết kế phần cứng sáng tạo từ thời xưa vẫn có thể giúp giải quyết những bài toán phức tạp về system-level software.
Kiến trúc RISC bị bỏ rơi Không, đó không phải là lỗi đánh máy Nhiều người biết hoặc đã nghe nói về kiến trúc Motorola 68000. Những bộ xử lý này đã...
(Theo liên kết này để quay lại trang m88k chính.)
PHẦN 1: Kiến trúc RISC bị bỏ rơi
Không, không phải lỗi đánh máy
Nhiều người biết hoặc đã nghe nói đến Motorola 68000 kiến trúc. Những bộ xử lý này đã được sử dụng trong nhiều máy: ở những thế hệ đầu tiên của Apple Macintosh máy tính, trong sự cạnh tranh không ngừng Amiga và máy tính gia đình Atari ST, ở nhiều máy trạm được xây dựng bởi Mặt trời, HP và NeXT (chỉ kể tên một số ít), mà còn trong nhiều ngành công nghiệp hệ thống và bảng mạch được xây dựng bởi Motorola, Nòng nọc, Heurikon hoặc Công nghệ hiệu suất (chỉ nêu tên một vài.)
Kiến trúc 68000 đã rất thành công, nhưng do CISC thiên nhiên với chế độ địa chỉ phức tạp và nhiều lệnh, Motorola đã không thể giữ được tiến lên trong cuộc cạnh tranh tốc độ.
Để có thể mang lại hiệu suất và megahertz, một bộ xử lý khác kiến trúc là cần thiết, một kiến trúc có thể mở rộng quy mô dễ dàng hơn.
Tại thời điểm này có lẽ bạn đang mong đợi tôi viết về PowerPC, điều đó cũng hóa ra là một kiến trúc thành công, được sử dụng trong các thế hệ tiếp theo của Apple Macintosh máy tính, trong các máy trạm (từ IBM và Bò , chủ yếu), và trong biểu tượng BeBox.
Nhưng giữa 68000 và PowerPC có màu đen cừu của gia đình. Một kiến trúc bộ xử lý hứa hẹn nhiều điều nhưng lại không giao chúng, và đã được định sẵn là được giao cho sự lãng quên, như thể đó là một giấc mơ tồi tệ.
Kiến trúc bộ xử lý đó là Motorola 88000 kiến trúc, hay gọi tắt là m88k.
Tóm tắt về m88k
Đã có hai thế hệ vi xử lý 88000 trước khi Motorola tái phân phối tất cả các kỹ sư của nó cho PowerPC.
Thế hệ đầu tiên bao gồm 88100 CPU, với tùy chọn bên ngoài 88200 cái gọi là CMMU: một con chip cung cấp cả bộ nhớ đệm và phương tiện quản lý bộ nhớ. Việc lựa chọn các chip riêng biệt cho phép các thiết kế không cần MMU được hoàn thành nhanh chóng và rẻ tiền, và NCD đã sử dụng 88100 rất nhiều trong Dòng X thiết bị đầu cuối vì lý do đó.
Tất cả các CMMU đều nằm trên cùng một cái gọi là P-Bus với bộ xử lý và phối hợp chặt chẽ với nó để thực hiện nhiệm vụ của mình. Và nhờ vào việc chia sẻ điều đó bus, chúng có thể giám sát lẫn nhau để đạt được sự kết hợp bộ đệm tự động trên các bộ xử lý. Hơn nữa, họ còn có thể hiển thị bản thân mình cho tất cả mọi người. bộ xử lý, khi chúng trả lời các lệnh cụ thể trên dải địa chỉ chuyên dụng: điều này cho phép một bộ xử lý nhất định thực hiện vô hiệu hóa bộ đệm hoặc bất kỳ MMU nào hoạt động thay mặt cho bộ xử lý khác (bằng cách gửi lệnh tới CMMU liên quan đến bộ xử lý đó) mà không cần phải làm gián đoạn bộ xử lý đó. Điều này làm cho việc triển khai đa bộ xử lý, từ quan điểm phần mềm, dễ dàng hơn nhiều so với trên kiến trúc cổ điển hơn.
Một ưu điểm khác được nhận thấy của các thành phần riêng biệt này là tùy thuộc vào nhu cầu của bạn về bộ nhớ đệm, bạn có thể sử dụng nhiều hơn hơn một chip 88200 trên mỗi bộ xử lý. Trên thực tế, trong khi các thiết kế cơ bản sẽ sử dụng hai (một cho bộ đệm lệnh, một cho bộ đệm dữ liệu), các thiết kế hiệu suất cao hơn có thể sử dụng tới tám người bạn đồng hành CMMU như vậy (có nhiều hơn tám, ngoài việc trở thành vấn đề nghiêm trọng về không gian bảng, cũng sẽ gây ra các vấn đề về độ trễ của bus và cường độ tín hiệu, vì tất cả các chip đều có được kết nối với cùng một P-Bus tốc độ cao.) Điều này hạn chế tốc độ chạy của chip 88100 và 88200; Và họ được xây dựng ở tốc độ từ 16 MHz đến 33 MHz, hầu hết là 25 MHz các bộ phận.
Thế hệ thứ hai cố gắng học hỏi từ những nhược điểm của 88100 và quay trở lại kiến trúc truyền thống hơn, đưa bộ nhớ đệm và MMU trở lại 88110 bộ xử lý (và, đối với các lập trình viên hệ thống, một mô hình ngoại lệ đơn giản hơn nhiều.) Ban đầu được cho là chạy ở tần số 50 MHz, với mục đích đạt tới 100 MHz trong tương lai, những bộ xử lý này gặp phải vấn đề về phần cứng, và trong một thời gian, không có bộ xử lý 50 MHz đời đầu nào có thể chạy ổn định ở mức đó tốc độ và phải được bán dưới dạng các bộ phận 40 MHz, tốc độ mà họ không cư xử không đúng mực điều đó nhiều...
Mặc dù những khiếm khuyết này cuối cùng đã được sửa chữa và các bộ phận chạy nhanh hơn 50 MHz thậm chí còn bắt đầu được sản xuất (có bằng chứng về các chip 60 MHz hiện có), Motorola đã rất vui vẻ rút phích cắm khi IBM gõ cửa yêu cầu trợ giúp với dự án PowerPC, dẫn đến thời gian tồn tại ngắn ngủi AIM (Apple, IBM, Motorola) liên minh.
Một số phần của thiết kế 88110 đã được đưa vào bộ xử lý PowerPC đầu tiên, đặc biệt là các bus ngoài của PowerPC 601 rất giống với các bus ngoài của 88110.
phần cứng m88k
Do thời gian tồn tại ngắn ngủi (khoảng 1988-1994) và lần đầu tiên thế hệ, độ phức tạp của thiết kế hệ thống, kiến trúc 88000 đã làm không thuyết phục được nhiều công ty phần cứng xây dựng hệ thống của họ trên nền tảng này kiến trúc.
Cho đến ngày nay, không còn nhiều thông tin về các hệ thống này. Paul Weissmann của OpenPA nổi tiếng, đã bắt đầu một điều tương tự, nhưng ít tham vọng hơn, nỗ lực ghi lại hệ sinh thái m88k, như "badabada". Trang web này không còn trực tuyến nữa, nhưng có một bản sao của phiên bản cuối cùng của trang web đó bật Kho lưu trữ Internet, cũng như về sự hiện thân hiện tại của Trang web m88k.com.
Những người sử dụng nổi tiếng nhất của các bộ xử lý này là:
- Motorola, cho riêng mình
MVME
Dòng bo mạch VME, với nhiều mẫu mã.
Một lưu ý về xe buýt VME:
Bus VME (Versa Module Eurocard) là một bus đơn giản, được thiết kế với 68000 lưu ý đến bộ xử lý, cho phép nhiều bo mạch độc lập chia sẻ cùng một 32-bit không gian địa chỉ bộ nhớ.
Hệ thống VME bao gồm một bảng nối đa năng thụ động , trong đó cần thiết Bo mạch VME đã được cắm; bảng nối đa năng cho phép một số tín hiệu được truyền qua giữa tất cả các khe.
Bảng VME có thể thuộc bất kỳ loại nào; tồn tại các bo mạch xử lý, bo mạch bộ nhớ, Bo mạch I/O (chẳng hạn như bộ điều khiển Ethernet hoặc SCSI), bo mạch đồ họa, tín hiệu bảng mua lại...
Một trong các bo mạch VME (thường là bo mạch chiếm khe ngoài cùng bên trái) là bộ điều khiển hệ thống và được phép thực hiện một vài hành động chung, chẳng hạn như như gửi tín hiệu đặt lại trên toàn bộ xe buýt.
Sau đó, các bo mạch có thể thực hiện các chu trình truy cập bộ nhớ trên xe buýt; truy cập xe buýt có thể rộng 8, 16 hoặc 32 bit, sử dụng địa chỉ 16, 24 hoặc 32 bit, đồng thời mang theo bộ sửa đổi địa chỉ (tương đương với hàm 68000 mã ) có thể được sử dụng để hạn chế quyền truy cập; những cái này thường được sử dụng để thực hiện việc phân biệt người giám sát/người dùng với chi phí thấp, trên các hệ thống không cần MMU chính thức.
Các bo mạch cũng có thể gửi yêu cầu ngắt tới bus, với ngắt 8 bit số vectơ; các ngắt thường được xử lý bởi bộ điều khiển ngắt trên bộ điều khiển hệ thống.
Ban đầu là bus địa chỉ và dữ liệu 32 bit, với mỗi bo mạch VME có dạng 6U yếu tố có hai đầu nối lớn cắm vào bảng nối đa năng, nó cũng có thể cho một bo mạch chỉ sử dụng một đầu nối, giảm độ rộng bus của nó xuống 24 bit địa chỉ và 16 bit dữ liệu và vừa với 3U. Và đối với thành phần lớn hơn nhu cầu tích hợp, hệ số dạng 9U cũng đã tồn tại và được sử dụng chẳng hạn của Sun cho các dòng máy trạm Sun-3 và Sun-4 (cũng như một số mẫu Sun-2), hoặc bởi Encore với các máy tính Encore 91 dựa trên 88100.
Gần cuối những năm 1990, nhiều người sử dụng xe buýt VME bắt đầu chuyển sang sử dụng nhanh hơn và có chức năng tương đương Xe buýt compactPCI.
-
MVME180 và MVME181
Những tấm ván đầu tiên này là một nửa nguyên mẫu, một nửa là mẫu thử nghiệm.Trích dẫn các trang hướng dẫn từ hệ điều hành của Motorola cho bo mạch này:
mvme181 là nền tảng CPU có MPU MC88100, hai MC88200 CMMU, hai cổng giao tiếp nối tiếp RS-232C được điều khiển bởi 68692 DUART, pin dự phòng theo thời gian thực đồng hồ/lịch, 8 MB DRAM tích hợp cổng kép và 512 KB của chương trình cơ sở chứa Trình gỡ lỗi và chẩn đoán MVME181BUG- Gói tic.
Bo mạch MVME180 với bộ xử lý 20 MHz và CMMU.- MVME187
Một biến thể thành công của 68040 -dựa trên Bảng MVME167, thay thế bộ xử lý bằng 88100.Trích dẫn các trang hướng dẫn từ hệ điều hành của Motorola cho bo mạch này:
mvme187 là nền tảng CPU có MPU MC88100, hai MC88200 CMMU, 32, 40, 48 hoặc 64 MB cổng kép tích hợp (gác lửng), 8 KB RAM tĩnh dự phòng pin, 128 Kb của RAM tĩnh dễ thay đổi, đồng hồ/lịch thời gian trong ngày, Giao diện thu phát Ethernet (Intel 82596CA), bốn EIA- Cổng giao tiếp nối tiếp 232-D (Cirrus Logic CD2400/2401), giao diện bus SCSI-2 (NCR 53C710), tương thích với Centronics cổng máy in song song (ngoại trừ trên hệ thống M8120), cấu hình có thể có bản đồ địa chỉ cục bộ và VMEbus, bốn bộ đếm thời gian đánh dấu và bốn ổ cắm ROM trong đó hai ổ chứa MVME187BUG Gói gỡ lỗi và chẩn đoán. Ngoài ra, hệ thống M8120 chứa một chip Cirrus Logic CD2400 bổ sung mà từ đó hai cổng giao tiếp nối tiếp bổ sung được hiển thị.
Bo mạch MVME187 với bộ xử lý 25 MHz 88100 và 88204 CMMU hiếm có, với thẻ nhớ lửng đã được gỡ bỏ. (88204 tương tự lên 88200, nhưng cung cấp 64KB bộ nhớ đệm thay vì 16KB.)- MVME188
Một bộ nhiều bo mạch, dành cho các hệ thống đa bộ xử lý, cho phép tối đa bốn bộ xử lý dành riêng mô-đun HYPER bảng con gái.Trích dẫn các trang hướng dẫn từ hệ điều hành của Motorola cho bo mạch này:
MVme188 là một nền tảng CPU bao gồm: một, hai, hoặc bốn MPU MC88100, hai, bốn hoặc tám CMMU MC88200, từ 16 MB đến 128 MB DRAM tích hợp cổng kép, 2 KB RAM dự phòng pin, địa chỉ cục bộ và VMEbus có thể định cấu hình bản đồ, hai cổng giao tiếp nối tiếp RS-232C được điều khiển bởi một 68692 DUART, bốn bộ hẹn giờ có thể lập trình, pin dự phòng đồng hồ/lịch thời gian thực và 512 KB phần sụn chứa Trình gỡ lỗi MVME188BUG và Gói chẩn đoán.
Lắp ráp bảng MVME188 với HYPERmodule 1P64 (bộ xử lý 88100 20 MHz đơn và bốn CMMU 88200.)
Lắp ráp bảng MVME188A với HYPERmodule 4P128 (bốn bộ xử lý 88100 25 MHz và tám CMMU 88200.)- MVME197
Các bo mạch dựa trên 88110 duy nhất có một hoặc hai bộ xử lý.Trích dẫn các trang hướng dẫn từ hệ điều hành của Motorola cho bo mạch này:
Mvme197 là nền tảng CPU có một hoặc nhiều MPU MC88110. 197LE chứa một MC88110 duy nhất và có thể được cấu hình với 32, 64, 128, 256, 384 hoặc 512 MB cổng kép tích hợp bộ nhớ lửng lên tới tối đa 576 MB. Con 197SP chứa một MC88110 duy nhất, có thể được cấu hình với 128, 256, 384 hoặc bộ nhớ lửng tích hợp cổng kép 512 MB lên tới mức tối đa tối thiểu là 768 MB và chứa 256 KB Bộ nhớ đệm phụ được điều khiển bởi Bộ điều khiển bộ nhớ đệm thứ cấp MC88410. 197DP chứa hai MC88110, có thể được cấu hình với 128 hoặc 256 MB tầng lửng bộ nhớ tích hợp cổng kép lên tới tối đa 1,2 GB và chứa 256 KB Bộ nhớ đệm phụ được điều khiển bởi một MC88410 cho mỗi bộ xử lý. 197QP chứa hai MC88110/410 cặp, 256 MB một tầng lửng hai bộ xử lý bộ nhớ hai cổng. Mỗi bộ xử lý có 256 KB thứ cấp bộ đệm. Tất cả các bo mạch mvme197 đều có pin 8 KB sao lưu RAM tĩnh, đồng hồ/lịch thời gian trong ngày, Ethernet giao diện thu phát (Intel 82596CA), bốn nối tiếp EIA-232-D cổng giao tiếp (Cirrus Logic CD2400/2401), bus SCSI-2 giao diện với DMA (NCR 53C710), tương thích với Centronics cổng máy in song song, địa chỉ cục bộ và VMEbus có thể định cấu hình bản đồ, sáu bộ đếm thời gian đánh dấu và bốn ổ cắm ROM, trong đó có hai ổ cắm chứa Trình gỡ lỗi MVME197BUG và Gói chẩn đoán.
- Omron, người có nền tảng 68000 của riêng mình Luna dòng máy trạm, được thiết kế Luna-88k với tối đa bốn bộ xử lý 88100, sử dụng lại khung máy tính để bàn hiện có của mặt trăng. Những hệ thống này được sử dụng nhiều ở CMU để thực hiện CMU Mach hệ điều hành.
見かけたら保護を!
Hai máy trạm Omron Luna-88K và một máy trạm Omron Luna-88K2 ở phía dưới.
(Ảnh của Kenji Aoyama)- Dữ liệu chung đã chọn sử dụng 88100 (và sau này là 88110) cho
AViiON
dòng máy trạm, nhưng đã chuyển sang
Intel
Pentium
bộ xử lý sau khi Motorola ngừng sản xuất bộ xử lý 88000.
Hộp pizza AViiON 300, đang mở (bấm vào để xem hình lớn hơn.)
Lưu ý cách đặt các mô-đun bộ nhớ ở vị trí nghiêng, để giữ chiều cao đủ nhỏ.
Máy tính để bàn AViiON 400, phía trước.
(Ảnh của Chris Tribo)
Lưu ý các chân kim loại có tác dụng tăng gấp đôi bề mặt tiếp đất của hệ thống.
Có một khay quạt lớn ở dưới đáy thùng máy chân để đảm bảo quạt không bị che khuất.
hệ điều hành m88k
Motorola đã sử dụng phiên bản riêng của mình AT&T Unix Hệ thống III, rồi sau này Hệ thống V, bật dòng bo mạch VME của nó. Dữ liệu chung được sử dụng riêng DG/UX hương vị của Unix. Omron đã có một phiên bản dựa trên BSD có tên là UniOS.
Tất cả các hệ thống này đều là độc quyền, có rất ít hoặc không có sự phổ biến nguồn của chúng. mã.
Tuy nhiên, CMU Mach, là một hệ điều hành nghiên cứu, có hầu hết nguồn gốc của nó. mã có sẵn theo giấy phép miễn phí (một số phần, chẳng hạn như IBM RS/6000 cảng, đã bị cản trở do việc sử dụng lại mã nguồn độc quyền và có thể ngày nay bị thất lạc - Tôi đã dành chút thời gian vào đầu những năm 2000 để theo dõi thông tin cụ thể đó mã xuống, vô ích.)
(Nếu bạn có bản sao của mã nguồn đó hoặc biết thêm về nó ở đâu, vui lòng liên hệ với tôi!)Sự tồn tại của mã CMU Mach cho Luna-88K đã cho phép một nhân viên của Motorola, Nivas Madhur , để chuyển OpenBSD sang MVME187 vào năm 1995, và đây là cách câu chuyện m88k trong OpenBSD bắt đầu.
Nếu cổng đó không tồn tại thì kiến trúc m88k có lẽ còn kém hơn nữa được biết đến ngày nay.
OpenBSD/mvme88k, những ngày đầu
Mã của Nivas Madhur đã được nhập vào OpenBSD ngay sau khi tạo Kho lưu trữ mã nguồn OpenBSD, vào tháng 10 năm 1995.
Nhưng Madhur không có thời gian làm việc ở OpenBSD và khi anh rời Motorola một thời gian sau không còn ai trông coi bến cảng. Trước khi anh rời đi, anh ấy đã chia sẻ mã mới nhất của mình với Dale Rahn, người đang chăm sóc mvme68k cổng sang thẻ Motorola VME dựa trên 68000, vì những bo mạch này có mọi thứ trong phổ biến, nhưng bộ xử lý.
Rahn có ý định thay thế cái hiện có OpenBSD/mvme88k mã với cái mới đó phiên bản, nhưng sẽ không có thời gian và nguồn lực để duy trì cổng sau đó.
Hạt nhân đã được xử lý vào ngày 3 tháng 3 năm 1996 trong hai lần chuyển giao.
Đầu tiên cam kết:Thử lần thứ ba khi nhập cổng mvme88k. Đây là một hạt nhân hoạt động từ nivas. Vùng người dùng và trình biên dịch vẫn cần được xử lý. Đảm bảo quá trình nhập được thực hiện từ thư mục nào.
Dọn dẹp sau khi nhập. Điều này dường như cũng đưa lên phiên bản hiện tại.
...và vùng đất người dùng đã được chăm sóc vào ngày 25 tháng 3.
Ok đây là vùng người dùng mvme88k, trừ một số phần quan trọng. như, thay đổi ld cần phải được hợp nhất. Được biết, các thư viện dùng chung và C++ không làm việc. Nếu ai muốn tiến lên và chiếm lấy cổng mvme88k thì hãy làm. Tôi đã bỏ rơi nó khi nhà phát triển ban đầu, Nivas, rời bỏ công ty cũ của mình công việc và bắt đầu một công việc mới. Tôi đang cố gắng biến bến cảng thành một hình dạng mà ai đó có thể tiếp quản.
Hạt nhân là một hỗn hợp các mảnh vụn được lấy từ khắp mọi nơi:
- các bộ phận dành riêng cho m88k được lấy từ CMU Mach.
- trình điều khiển thiết bị tích hợp được lấy từ OpenBSD/mvme68k...
- ...do đó đã mượn một số bộ phận, chẳng hạn như trình điều khiển bộ điều khiển SCSI, từ Cổng NetBSD/amiga.
Không có nhiều chuyện xảy ra cho đến tháng 8 năm 1998, khi Steve Murphree, Jr. , bắt đầu tiếp quản cảng và biến nó thành hiện thực.
Vào ngày 1 tháng 11, anh ấy đã sửa một lỗi nghiêm trọng trong mã hóa lệnh xcr trong bộ lắp ráp.
Thật không may, Murphree là loại nhà phát triển đang làm việc riêng cho trong một thời gian, dường như đổ tất cả công việc của mình lên cây trong một vài lần xác nhận, trộn lẫn những thay đổi không liên quan và lại biến mất trong một thời gian. Điều này ổn miễn là anh ấy là người duy nhất làm việc trên mvme88k, nhưng nó sẽ không hoạt động lâu dài hạn.
Vào tháng 12 năm 1998, anh đã đạt đến trạng thái hệ thống hoạt động ổn định và có khả năng biên dịch lại hầu hết chính nó. Phần còn thiếu cuối cùng, cấu hình các chỉ thị dành cho trình biên dịch (lúc đó là gcc 2.8.1), đã được cam kết vào tháng 2 1999.
Vào ngày 15 tháng 2, anh ấy đã hoàn thành bản dựng ảnh chụp nhanh OpenBSD/mvme88k. Đây là ảnh chụp nhanh OpenBSD/mvme88k đầu tiên được xây dựng thành công và sẽ là ảnh chụp nhanh cuối cùng một trong hơn bốn năm, mặc dù chưa ai có thể biết điều này.
Vào ngày 26 tháng 5, Marc Espie sẽ cập nhật trình biên dịch hệ thống lên ngày 17 tháng 5 ảnh chụp nhanh của EGCS, gần giống với gcc 2.95 trong tương lai.
Nhiều bản cập nhật tiếp theo vào tháng 6 và tháng 7, cho đến ngày 23 tháng 8, khi bản chính thức Bản phát hành gcc 2.95.1 đã được nhập.
Lưu ý về EGCS và GCC:
Nếu bạn không biết hoặc không nhớ phần đó của lịch sử GCC, quá trình phát triển của GCC, trong loạt 2.x, ngày càng trở nên bảo thủ hơn và GCC vẫn "mắc kẹt" ở phiên bản 2.7.2.1 trong nhiều năm và chỉ phát hành phiên bản 2.8 phiên bản dưới áp lực của các nhà phát triển và người dùng C++, những người cần phiên bản tốt hơn Hỗ trợ C++ được cung cấp bởi GCC 2.8.
Đồng thời, một số nhóm được thành lập ở để cải thiện GCC, tập trung mạnh vào việc tối ưu hóa tốt hơn để để sử dụng tốt hơn phần cứng hiện đại. Nhóm lớn nhất trong số này là Nhóm "Pentium GCC", nhóm đã thực hiện rất nhiều công việc trên phần phụ trợ i386 cho Họ Intel 80386.
Cuối cùng, tất cả các nhóm sáp nhập lại với nhau và phát hành cái được gọi là EGCS, Hệ thống trình biên dịch GNU thử nghiệm (phát âm là "trứng".)
Đã có một số xích mích giữa GCC và EGCS, nhưng sau đó, do có quá nhiều tính năng động tốt hơn của EGCS, FSF đã quyết định ngừng sự phát triển của GCC và bổ nhiệm EGCS làm GCC mới, và những gì lẽ ra EGCS 1.2 đã được phát hành dưới dạng GCC 2.95.
Rất tiếc, bản cập nhật trình biên dịch này đã bị lỗi trên mvme88k - bản 2.8 trình biên dịch đã được biết là không phải lúc nào cũng tạo ra mã chính xác và trình biên dịch tối ưu hóa phải bị vô hiệu hóa khi nhắm mục tiêu mvme88k, nhưng 2,95 đã đạt đến trạng thái mà nó thậm chí không thể tự biên dịch lại, ngay cả với tối ưu hóa bị vô hiệu hóa.
Vì điều này mà Murphree vẫn tiếp tục làm việc với cổng nhưng vẫn sử dụng phiên bản 2.8 trình biên dịch và vô hiệu hóa việc xây dựng trình biên dịch mới cho đến khi anh ta có thể nhận trợ giúp hoặc tự mình tìm ra cách khắc phục gcc.
Thất bại đó cũng khiến anh tập trung vào các phần khác của cây OpenBSD và ông đã đóng góp hỗ trợ cho 68060 -dựa trên Các bo mạch MVME172 và MVME177 được chuyển sang cổng OpenBSD/mvme68k vào đầu năm 2000. Ông cũng đảm nhận việc duy trì ahc tài xế cho Adaptec AIC-78xx SCSI Gia đình điều khiển vào tháng 3 năm đó.
Con đường riêng của tôi đã vượt qua m88k vào cuối năm đó. Tôi đã bị hấp dẫn bởi cổng này tới một kiến trúc mà tôi chưa từng biết tới và vào tháng 9 ngày IRC, Tôi đã "gặp" Manuel Odendahl, người đang hoàn thành nghiên cứu khoa học máy tính của mình trong Karlsruhe, Đức , và đã có mối liên hệ tốt với mọi người ở JPAVES Gmbh trực tuyến Unix, một công ty bán các dịch vụ liên quan đến Unix, từ phát triển đến hỗ trợ. Công ty đó có rất nhiều phần cứng Motorola 88000 đang được ngừng hoạt động. Anh ấy đã cho tôi liên lạc với Eckhard Schönknecht tại JPAVES và tôi bắt đầu tổ chức một chuyến đi tới Karlsruhe.
Chuyến đi đó đã được lên kế hoạch vào đầu tháng 10, nhưng gần như bị hủy vì có đã (như thường lệ...) các cuộc đình công ở Pháp xảy ra cùng lúc, và các kho xăng bị tài xế xe tải chặn vào cuối tháng 9. Chuyến đi đi về về từ chỗ tôi hơn 1300 km, không đời nào tôi có thể làm điều đó mà không cần phải nạp lại một vài lần. Thật may mắn cho tôi, cuộc đình công đã kết thúc đúng lúc để tôi có thể đi tiếp. đường mà không sợ hết xăng.
Sau khi gặp Manuel Odendahl tại nhà bố mẹ anh ở Strasbourg, Pháp, chúng tôi đã lái xe đến Karlsruhe để chọn bảy hệ thống MVME188 ở đó. Thỏa thuận giữa chúng tôi là tôi sẽ đưa ba người họ đến ký túc xá của Manuels tại Hadiko đối với anh ấy và câu lạc bộ máy tính mà anh ấy là thành viên, và giữ bốn cái còn lại cho tôi (cũng như một loạt phụ tùng thay thế, cáp, v.v.) Và tất nhiên, vì không có gì ngoài phần mềm là miễn phí ở đây thế giới, tôi phải trả JPAVES DM 1500 (khoảng 750 EUR) cho tất cả phần cứng đó.
Nhà phát triển OpenBSD Christian Weisgerber, người sống cách đó không xa, đã tham gia cùng chúng tôi tại Karlsruhe, mặc dù muộn hơn dự kiến (văn phòng JPAVES ở đầu phía tây của Kaiserallee, nhưng anh ta đã phạm sai lầm và đỗ xe ở chỗ đầu phía đông của Kaiserstraße và phải đi bộ rất nhiều, rất nhiều, rất nhiều hơn anh ấy mong đợi...) để giúp di chuyển phần cứng.
Tuy nhiên, tôi lo lắng rằng tôi sẽ cần bo mạch MVME187 để có thể trợ giúp cổng OpenBSD/mvme88k, vì đây là bo mạch duy nhất được biết là hoạt động ở khoảnh khắc; vì vậy mọi người đã đồng ý rằng tôi cũng sẽ mua thêm một bảng MVME187 đến khung xe bảy tội lỗi.
Vì vậy, sau khi thu thập tất cả các thiết bị MVME188, chúng tôi đã lái xe bằng một trong những thiết bị của JPAVES nhân viên đến chỗ riêng của anh chàng; sau đó anh ta đi đến phòng máy của mình, đăng nhập trên một thiết bị đầu cuối, tạm dừng hệ điều hành, tắt nguồn VME nhỏ, cẩn thận gỡ một bảng MVME187 ra khỏi nó và đưa cho tôi.
Đây là bo mạch MVME187 có tốc độ trung bình 25 MHz với bộ nhớ 32 MB. hy vọng đủ tốt để giúp tôi bắt đầu.
Bo mạch MVME187 được đề cập ở trên, cùng với bo mạch MVME177 có tầng lửng bộ nhớ, dùng chung khung VME 3 khe. Do thiếu các khe đĩa thích hợp cho khung đó, một của các đĩa chỉ đơn giản được đặt lên trên một tấm xốp dày, để cách nhiệt nó khỏi khung xe.(Bảng đó không chỉ giúp tôi bắt đầu, như bạn sẽ thấy bên dưới, nhưng đó là công việc chính của tôi trong mvme88k trong nhiều năm, cho đến khi tôi có thể thay thế nó bằng bo mạch 33 MHz. Cho đến hôm nay tôi vẫn có bo mạch này và thỉnh thoảng chạy thử.)
Tất cả những gì tôi cần bây giờ là cách thiết lập chiếc máy đó. Vì lý do nào đó, tôi đã hoàn toàn bỏ sót 2,5 chương trình nhị phân do Steve Murphree xây dựng (không có thực sự là 2.5 phát hành nhưng ảnh chụp nhanh HIỆN TẠI 2,4 gần với điểm cắt phát hành.)
Tôi liên tục yêu cầu anh ấy chụp nhanh các tệp nhị phân gần đây.
Ngày: Thứ năm, 28/12/2000 23:57:58 +0000 Đến từ: Miod Vallat Kính gửi: Steve Murphree Chủ đề: tin tức m88k ? Xin chào, nhìn vào các thay đổi nguồn, bạn đã có thời gian chơi với mvme88k máy móc. Thật tuyệt vời! Bạn có nghĩ rằng bạn sẽ có một ảnh chụp nhanh (chỉ cần base + comp + bsd đủ) cho tôi sớm chưa? Tôi có một thiết lập mvme68k đang hoạt động tốt, vì vậy tôi có thể tạo một đĩa có khả năng khởi động và hoạt động ngay lập tức... Tôi chỉ cần điền nó. Chúc mừng, Miod Murphree hứa sẽ chụp ảnh nhanh cho "cuối tuần đầu tiên của tháng Giêng." Rồi những sự chậm trễ khác ngăn cản anh ta giao bất cứ điều gì.
May mắn thay, một thời gian sau tôi nhận thấy 2,5 bit.
Ngày: Thứ Hai, 5 tháng 2 năm 2001 22:27:24 +0000 Đến từ: Miod Vallat Kính gửi: Steve Murphree Chủ đề: Tôi ngốc quá (mvme88k) Xin chào, Tôi vừa nhận ra rằng khi thực hiện tìm kiếm ftp rằng ảnh chụp nhanh 2,5/mvme88k là vẫn có sẵn ở một số nơi. Tôi không tìm thấy nó trên ftp.openbsd.org khi tôi nhận được hộp m88k vì tôi đã ngây thơ nhìn vào snapshots/, không phải thư mục phát hành. Vì vậy về cơ bản tôi đã lãng phí thời gian của mình trong khi Tôi có thể quản lý để có thứ gì đó hoạt động trên mvme187 và nâng cấp lên -bản thân tôi hiện tại. Tôi đang tìm nạp các tập tin ngay bây giờ, có thể sẽ mất vài ngày (một vài nghĩa là hàng giờ mỗi ngày), nhưng sau đó tôi sẽ có thứ gì đó để chơi nếu ảnh chụp nhanh của bạn bị trễ. Sau đó, Miod (Tôi vẫn đang sử dụng một Internet quay số kết nối vào thời điểm đó. Tốc độ chậm, ở tốc độ 31,2Kbps, vì đường dây điện thoại của tôi thậm chí còn không ổn định ở tốc độ 33,6Kbps. Do đó việc tải xuống các tệp lớn chẳng hạn như ảnh chụp nhanh OpenBSD thực sự sẽ mất giờ để hoàn thành.)
Vì bo mạch MVME187 tôi được tặng không có phiên bản PROM gần đây nên nó thiếu các lệnh liên quan đến mạng và không thể khởi động mạng. Tôi đã phải tìm một cách để thiết lập một đĩa với các khối khởi động mvme88k và đặt bsd.rd trình cài đặt trong hệ thống tập tin gốc. (Không có miniroot nào sẵn sàng chạy hình ảnh bạn có thể chỉ cần lưu vào đĩa bằng cách sử dụng dd trên máy khác, vào thời điểm đó cũng vậy.)
May mắn thay, trong số những phụ tùng tôi mua được từ JPAVES có một chiếc MVME147. bo mạch (25 MHz 68030, bộ nhớ 8 MB) với bộ điều khiển Ethernet chiên, có thể chạy OpenBSD/mvme68k. Tôi đã phải cấu hình mạng bằng cách sử dụng SLIP, và nó thực sự chạy khá tốt theo cách đó cho đến khi tôi có thể thay thế bảng mạch bằng một bảng MVME147 tương tự khác trong tình trạng hoạt động hoàn chỉnh, khoảng một năm sau này.
Tôi đã sử dụng nó để thiết lập đĩa mvme88k. Đây là một nhiệm vụ dễ dàng thực hiện trên lý thuyết, tuy nhiên tôi mất nhiều thời gian hơn dự kiến do vấn đề chấm dứt SCSI: đĩa tôi định sử dụng cho MVME187 đã cắm điện trở kết thúc trong đó tôi đã không nhận thấy; và tất nhiên tôi đã đặt nó trước đĩa mvme68k trong chuỗi SCSI khiến máy thấy đĩa mới setup nhưng không thấy còn nhìn thấy đĩa để khởi động nữa và tôi không hiểu tại sao. Tôi phải mất một thời gian để nhận ra gói điện trở bên dưới đĩa.Lưu ý về việc chấm dứt chuỗi SCSI:
Tất cả các thiết bị SCSI được kết nối thành một chuỗi bằng dây cáp. Tương tự với 10base2 (BNC), chuỗi phải được kết thúc bằng điện trở ở cả hai đầu. Thông thường, một đầu của chuỗi là bộ điều khiển SCSI được tìm thấy trên tàu. máy tính hoặc trong một bảng mở rộng và nó có chứa các đầu nối thích hợp điện trở.
Thiết bị cuối cùng trong chuỗi phải đảm nhiệm việc chấm dứt; điều này có thể được thực hiện hoặc với gói điện trở chuyên dụng, thường được sử dụng với các thiết bị SCSI bên ngoài trong bao vây riêng của họ, được gọi đơn giản là "thiết bị đầu cuối SCSI bên ngoài" hoặc bởi đặt điện trở thực tế vào một vị trí dành riêng trên thiết bị cuối cùng.
Để làm cho cuộc sống của mọi người đơn giản hơn, những gói điện trở này đã được thay thế bằng các jumper cấu hình đơn giản (nói cách khác, các điện trở bây giờ luôn luôn hiện diện trên các thiết bị SCSI và jumper sẽ kiểm soát xem chuỗi SCSI có sẽ đi qua hoặc đi qua chúng.)
Khi khả năng cắm nóng được thêm vào phần cứng SCSI, các thiết bị cao cấp cũng có thể hoạt động ở chế độ "chấm dứt tự động", nơi họ có thể phát hiện nếu chúng là thiết bị cuối cùng của chuỗi và sẽ tự động kích hoạt điện trở kết thúc trong trường hợp này.
Nếu, giống như tôi trong tình huống trên, bạn mắc sai lầm khi đặt dấu chấm dứt điện trở ở giữa chuỗi, mọi thứ đặt sau điện trở sẽ trở nên vô hình đối với bộ điều khiển SCSI. Vì vậy hãy cẩn thận khi mày mò nhiều thiết bị SCSI trên phần cứng cũ!
Ngày: Thứ sáu, 16/02/2001 00:16:56 +0000 Đến từ: Miod Vallat Kính gửi: Steve Murphree Chủ đề: Cái mvme88k SBC chết tiệt này hoạt động được! Xin chào, 187 khởi động 2,5 bsd.rd tốt. Tuy nhiên, bsd hoảng sợ (và có những biểu hiện kỳ lạ hành vi trước đây, chẳng hạn như không tìm thấy địa chỉ ethernet của tích hợp tức là chip). Vì vậy, tôi đang cố gắng xây dựng kernel -current từ 2.5 bsd.rd, trong môi trường chroot. Tất nhiên, quá trình xây dựng không thành công)-: Tinh chỉnh -L đối số thành ld làm cho giai đoạn liên kết hoạt động (tức là libgcc.a là đã tìm thấy) và tôi sẽ kiểm tra hạt nhân này sau một phút. Ồ, BTW, có đó không bất kỳ lý do nào để có hai lần -lgcc trong dòng lệnh LD trong Arch/mvme88k/conf/Makefile.mvme88k ? Kèm theo là dmesg - dường như có một số vấn đề chồng chéo, làm tôi tự hỏi liệu sự thay đổi của msgbuf trong khoảng từ 2.6 đến 2.7 có phải là không được thực hiện chính xác với giá 88k... Và msgbuf dường như quá nhỏ để chứa toàn bộ dmesg. Dù sao thì kernel là M187 chứ không phải GENERIC. Được rồi, đã đến lúc khởi chạy một bản dựng sẵn trên hộp và cập nhật đất người dùng. Và sau đó, hãy tính tôi vì đã hack nghiêm trọng vào vòm này ! Miod hạnh phúc v=0x802 \^O\M-l\^D\M-lreal mem = 33550336 tận dụng mem = 28889088 (7053 trang) sử dụng 435 bộ đệm chứa 1781760 byte bộ nhớ loại máy mainbus0 (root) MVME187 bugtty0 tại mainbus0 addr 0xfff45000: bugtty pcctwo0 tại mainbus0 addr 0xfff00000: rev 0 clock0 và pcctwo0 ipl 5: VME1x7 sclock0 và pcctwo0 ipl 5: VME1x7 nvram0 tại pcctwo0 offset 0xc0000: MK48T08 len 8192 cl0 và pcctwo0 offset 0x45000 bảng điều khiển ipl 3 siop0 tại pcctwo0 offset 0x47000 ipl 2: phiên bản 0 target 7 scsibus0 và siop0: 8 mục tiêu siop0: mục tiêu 0 hiện đã đồng bộ, chu kỳ = 100ns, offset = 8 thăm dò (siop0:0:0): Mã lỗi Sense 0 sd0 tại scsibus0 targ 0 lun 0: SCSI2 0/cố định trực tiếp sd0: 510MB, 2800 trụ, 4 đầu, 93 giây, 512 byte/giây, tổng cộng 1045242 giây vme0 tại pcctwo0 offset 0x40000: cơ sở vectơ 0x80, bộ điều khiển hệ thống vme0: sử dụng tham số BUG vme0: 1phys 0x02000000-0xefff0000 đến VME 0x02000000-0xefff0000 vme0: 2phys 0xff000000-0xff7f0000 đến VME 0xff000000-0xff7f0000 vme0: 3phys 0x00000000-0x00000000 đến VME 0x00000000-0x00000000 vme0: 4phys 0x00000000-0x00000000 đến VME 0x00000000-0x00000000 vme0: vme tới cpu irq cấp 1:1 vmes0 tại vme0 vmel0 tại vme0 tức là0 tại pcctwo0 offset 0x46000 ipl 1: địa chỉ 08:00:3e:21:06:d9 thiết bị khởi động: sd0 root trên sd0a rootdev=0x400 rrootdev=0x800 rawde Bây giờ tôi có thể bắt đầu xây dựng một vùng người dùng mới hơn, với quy mô nhỏ và một chút. thất thường (đọc: bị thúc đẩy bởi nhu cầu ngay lập tức có được một tệp nhị phân cụ thể đi làm), các bước. Vào thời điểm đó, một số lệnh xem xét nội tâm kernel, chẳng hạn như ps, đã truy cập trực tiếp vào bộ nhớ kernel thông qua sự trợ giúp của BSD cụ thể libkvm (ngày nay họ vẫn làm điều này, nhưng chỉ dành cho kernel coredumps; việc truy cập vào thông tin kernel trực tiếp được thực hiện bằng một dựa trên sysctl giao diện) và không hoạt động với kernel mới hơn mà tôi đã tạo.
Vì vậy, tôi cần xây dựng một libkvm mới và sau đó là các công cụ tùy thuộc vào nó. Nhưng để xây dựng một libkvm mới, tôi cũng cần một bản cập nhật thực hiện nhị phân. Vì vậy, tôi đã đạt được tiến bộ nhờ một số lần thử và sai hoặc bỏ qua một số bản dựng các bước (chẳng hạn như tính toán các trang hướng dẫn được định dạng sẵn) khi chúng không hoạt động nhưng trong trạng thái hiện tại của hệ thống của tôi.
Gần cuối tháng 2, tôi đã xây dựng lại phần lớn vùng đất của người dùng và ổn định hơn hệ thống. Tuy nhiên, tôi vẫn gặp một số vấn đề.
Ngày: Thứ sáu, 2 tháng 3 năm 2001 00:24:56 +0000 Đến từ: Miod Vallat Kính gửi: Steve Murphree Chủ đề: trạng thái mvme88k […] - mvme187 không ổn định 100%: sau 6, 7 ngày nó treo mà không báo trước. Bạn có thể ping máy, nhập ddb nhưng chỉ vậy thôi. quá trình hoạt động là chờ đợi một thao tác vào/ra hoàn tất nhưng không có gì xảy ra. Điều này đã xảy ra hai lần với tôi, tôi sẽ cố gắng tái tạo nó theo kiểu xác định... […] - Mình đã thêm cấu hình cho OpenBSD-m88k vào openssl để nó biên dịch với -O0 thay vì -O3, được xây dựng tốt nhưng điều này không hoạt động! ssh-keygen thất bại, ssh thất bại, v.v. Bạn có thể làm việc với openssl được không máy móc của bạn? […]
Phần cuối đó là do tùy chọn TIỀN ĐIỆN TỬ bị thiếu trong cấu hình kernel của tôi (tôi đang sử dụng kernel M187, không phải hạt nhân GENERIC, theo khuyến nghị của Steve Murphree, để tiết kiệm thời gian biên dịch kernel vì nó có ít trình điều khiển và tùy chọn thiết bị hơn, và không nhận thấy tùy chọn này bị thiếu.)
Không cần phải nói, tôi đã học được bài học của mình và chuyển sang hạt nhân GENERIC ngay sau đó. Nhưng sau đó tôi tình cờ phát hiện ra những hành vi lạ của kernel. Cuối cùng, chúng tôi phát hiện ra rằng ngăn xếp của bộ tải khởi động được thiết lập quá thấp trong bộ nhớ và hạt nhân GENERIC đã phát triển đủ lớn để có một phần dữ liệu của nó chồng lên khu vực đó, sau đó bị hỏng bởi bộ tải khởi động trước chuyển quyền điều khiển tới kernel. Điều này đã được khắc phục dễ dàng bằng cách liên kết giai đoạn thứ hai bộ tải khởi động ở mức cao hơn địa chỉ.
Tôi bận rộn với công việc phát hành sắp tới 2.9 phát hành và không làm gì trên mvme88k trong một thời gian.
Vào tháng 7, Joe Warren-Meeks đã yêu cầu cập nhật trạng thái cổng mvme88k trên linh tinh@; trong cuộc trò chuyện sau đây với anh ấy, tôi đã kể cho anh ấy một bản tóm tắt về công việc cần thiết để cập nhật các tệp nhị phân 2,5 thành mã hiện tại. Như bạn có thể thấy, điều này là tất cả mọi thứ nhưng thân thiện với người dùng.
Ngày: Thứ ba, 10/07/2001 01:16:41 +0000 Đến từ: Miod Vallat Kính gửi: Joe Warren-Meeks Tiêu đề: Re: mvme88k > Được rồi, tuyệt.. ngoài việc lập trình (thứ mà tôi không đủ giỏi) là > tôi có thể giúp gì được không? Vâng, lập trình (-; Nếu bạn có một máy mvme88k dự phòng với một ổ đĩa lớn, bạn có thể cố gắng theo dõi -current trên máy của bạn và báo cáo mọi vấn đề - tôi biết của một số, nhưng có lẽ tôi sẽ nhớ những người khác. Về cơ bản quy trình như sau (không dành cho người yếu tim): - cài đặt ảnh chụp nhanh 2.5 - cài đặt -nguồn HIỆN TẠI - biên dịch và cài đặt mới bộ nạp khởi động: cd /usr/src/sys tạo obj && tạo phụ thuộc && tạo && thực hiện cài đặt cd /usr/mdec cp -pf bootd /boot ./installboot /boot ./bootxx /dev/rsd0a - biên dịch kernel, khởi động lại bằng kernel này - nếu kernel luôn bị lỗi khi khởi động, hãy yêu cầu tôi xác nhận sửa lỗi CLKF_INTR, tìm nạp hiện tại với bản vá này và tiếp tục bước trước đó - tái tạo thiết bị: cp /usr/src/etc/etc.mvme88k/MAKEDEV /dev cd /dev ./MAKEDEV tất cả - cài đặt các tập tin mới bao gồm: cd /usr/src/bao gồm tạo điều kiện tiên quyết && bao gồm - biên dịch lại libkvm - biên dịch các công cụ đo lường quy trình cơ bản: ps, vmstat, v.v. - hãy thử xây dựng. Bạn có thể gặp phải vấn đề kernel hoảng loạn hoặc bị treo, hoặc những điều tốt đẹp khác. Sau này, awk có thể sẽ không hoạt động, cũng như, hãy đảm bảo luôn có sẵn tarball chụp nhanh 2.5 để có thể khôi phục chúng khi cần thiết. Phần thưởng là bạn có thể làm cho openssh hoạt động trên máy của bạn. Đúng! Những điều thú vị khác bạn có thể làm là viết các trang hướng dẫn sử dụng cho Các thiết bị dành riêng cho mvme88k: ssh (ex-siop), ve, vs, vx... Miod
Tôi đã bỏ bê cổng mvme88k một thời gian vì bận rộn với công việc trên các kiến trúc khác và 3.0 phát hành công việc, và sẽ chỉ tiếp tục công việc dọn dẹp kernel mvme88k vào tháng 11.
Đầu tháng 12, Steve Murphree nói với tôi rằng anh ấy đã hỗ trợ MVME197 và, do kết quả của công việc này, anh ấy đã có những thay đổi lớn đối với mvme88k mã hạt nhân. Anh ấy đã chia sẻ mã của mình với tôi vào ngày 5 tháng 12.
(Tất nhiên, khi nói "hoạt động hỗ trợ MVME197", anh ấy chỉ muốn nói rằng kernel đã được có khả năng khởi động và thăm dò thiết bị. Vùng người dùng chưa hoạt động chính xác, init sẽ cố gắng thả vào một cái vỏ, nhưng /bin/sh sẽ phân tách gần như ngay lập tức. Murphree sẽ đổ lỗi điều này cho những thay đổi kernel khác vào thời điểm đó. gây ra khá nhiều bất ổn trên tất cả các nền tảng và cuối cùng đã hoàn nguyên một số thời gian sau. Nhưng nguyên nhân thực sự là do lỗi trong mã của anh ấy, điều này khiến chúng tôi không thể thoát khỏi. và sẽ không được sửa chữa cho đến rất nhiều năm.)
Mã của anh ấy đã hạ cánh trên cây vào ngày 13 tháng 12. Thật không may, anh ấy đã làm việc trên cây nguồn từ khoảng giữa tháng 6 và đã có nhiều thay đổi xảy ra kể từ đó, không phải tất cả chúng đều là tác phẩm của tôi. Tất cả những thay đổi này sẽ được hoàn tác trong vài giây khi anh ấy đánh rơi tập tin của mình.
Theo cách nói hiện đại, anh ta đã quên (hoặc không quan tâm) thực hiện rebase mã của anh ấy, trước khi đưa nó vào cây nguồn OpenBSD. Kể từ khi cvs , cái Phần mềm SCM OpenBSD đang sử dụng sẽ không cho phép bạn ghi đè lên tệp có phiên bản lỗi thời, trừ khi bạn yêu cầu nó bỏ qua "chi tiết" đó một cách rõ ràng điều này không tình cờ. Có khả năng là anh ấy đã sao chép các tập tin mới nhất của mình qua lần kiểm tra gần đây, điều này đã ngăn cv phàn nàn vì siêu dữ liệu của tệp đã bị phù hợp với kho lưu trữ. Nhưng trong mọi trường hợp, dù anh ta có làm gì để vi phạm mã này, thì tốt nhất, hành vi cẩu thả.
(Và xin vui lòng tha cho tôi những câu "bạn đã sử dụng git..." chưa, vì SCM nguồn mở duy nhất tồn tại vào thời điểm đó là CVS; cũng không git cũng không Lật đổ đã tồn tại.)
Sau khi cập nhật cây nguồn của tôi, tôi không nhận thấy rằng anh ấy đã hoàn nguyên một số vẫn chưa thay đổi. Nhưng cố gắng xây dựng kernel nhanh chóng thất bại. Tại thời điểm này, tôi nghĩ rằng đó chỉ là một lỗi nhỏ nên tôi đã tiến hành khắc phục một vấn đề. Rồi cái khác. Rồi cái khác. Rồi cái khác... Khoảng mười lần xác nhận sau đó, cuối cùng tôi cũng có thể liên kết một kernel và thậm chí còn không chắc chắn nó sẽ khởi động.
Nhìn lại, lẽ ra tôi có thể làm điều này tốt hơn vì tôi vẫn còn bản sao của mã mà anh ấy đã chia sẻ với tôi vào ngày 5 tháng 12. Tôi có thể trích xuất nó, thu thập số phiên bản của tất cả các tệp mvme88k, so sánh với số phiên bản tại thời điểm đó anh ấy đã kết xuất mã của mình và thực hiện thao tác "rebase" cho mỗi tệp. Việc này thậm chí có thể được viết kịch bản để thực hiện nhanh chóng và nếu không có nhiều xung đột, việc này có thể được thực hiện trong nhiều nhất là vài giờ. Nhưng sau đó, nếu Murphree đã cư xử như vậy, điều này có thể là do có quá nhiều nhiều xung đột và anh ấy không thể bận tâm đến việc giải quyết chúng vào lúc này. Ai biết.
Dù sao thì đây cũng là suy đoán vô nghĩa vì tôi đã hoàn toàn quên mất mình vẫn còn lưu trữ kho lưu trữ này. Thành thật mà nói, tôi chỉ khám phá lại nó khi viết câu chuyện này, 24 năm sau này.
Ngoài ra, vì tôi không thể tin Murphree đã thực hiện sai thao tác cvs như vậy dù sao đi nữa, tôi không mong đợi phải sửa nhiều tập tin như vậy.
Ví dụ về các thông báo cam kết từ những nỗ lực của tôi trong việc lấy kernel để xây dựng hiển thị sự thất vọng ngày càng tăng trong buổi tối này.
- Thực hiện thành công việc này thông qua config(8), để bắt đầu...
- Steve, hãy chú ý đến những cảnh báo. ô nhiễm không gian tên cpp là BAD.
- Thêm một cam kết miễn phí nữa, nhờ có smurph@, để GENERIC có thể hoạt động.
- Bác miod có một GENERIC mvme88k và bác ấy muốn kernel biên dịch, eieio...
- Việc này quá khó vào lúc (gần như) 3 giờ sáng. Bây giờ GENERIC bước vào giai đoạn liên kết.
- Điền vào chỗ trống M88100...
- Thậm chí còn có nhiều cách viết đơn giản hơn để liên kết hạt nhân.
Tôi đã đề cập đến điều này trên phòng chat của các nhà phát triển OpenBSD vào một lúc nào đó. Tôi đã không muốn quá khắt khe với Murphree, vì đây hoàn toàn là công việc tình nguyện và chúng tôi tất cả đều cố gắng hết sức nên theo quan điểm của tôi, tôi không có quyền yêu cầu anh ấy sửa chữa mớ hỗn độn của anh ấy (trong khi tôi sẽ không bao giờ chấp nhận thái độ cẩu thả như vậy từ một đồng nghiệp được trả lương tại công việc hàng ngày của tôi.) Nhưng Theo de Raadt lại có quan điểm khác.
điều này sẽ khiến tôi mất tập trung khi đang sửa lỗi thiếu kiến thức CVS của Smurph. hắn cần bị đánh một trận không, trước tiên anh ấy cần phải học một khóa học về cvs. hãy cho chúng tôi biết điều này khác biệt như thế nào. thực hiện s/foo/bar ở phiên bản 1.4 và cam kết điều này trên 1.8 chắc chắn sẽ rất thú vị khi khắc phục. bạn ơi, bạn hiểu lầm rồi bảo anh ta sửa nó đi. đừng làm việc vớ vẩn của anh ta hiển thị anh ấy rằng bạn sẽ buộc anh ấy phải chịu trách nhiệm không, bạn hiểu lầm rồi. nếu tôi yêu cầu anh ấy sửa lỗi này thì kết quả sẽ Tệ hơn không, họ sẽ không như vậy. yêu cầu họ không được tệ hơn thì bạn lại ra kết quả và hỏi lại anh ta. và đợi mười năm? miod, CHÍNH XÁC những gì Espie đã nói và hỏi lại anh ta. giữa chừng, vậy thì sao? Bạn có một tập tin hoạt động. ừm. Xóa các thay đổi của anh ấy. và nếu anh ta không tuân theo, bạn sẽ cử Theo đến nhà anh ta để 'giải thích'. thật đấy! Tại sao anh ta sẽ học! làm tổn thương anh ấy. đó là lần duy nhất anh ấy sẽ học được. ngay bây giờ, hãy rút tập tin đó ra. bạn biết gì không? anh ấy sẽ KHÔNG quan tâm. anh ấy có cái cây CỦA NGÀI từ trước khi Rome được xây dựng, và anh ấy hài lòng với nó. vâng, anh ấy sẽ quan tâm. được rồi, tôi có nên khiến anh ấy quan tâm vì bạn là một kẻ yếu đuối không? được rồi. thỏa thuận. Tôi sẽ sao lưu công việc của anh ấy trong giây lát. Được rồi, tài khoản của anh ấy hiện đã bị vô hiệu hóa. Cho đến khi các bạn giải quyết được sự khác biệt của mình. Tôi sẽ để bạn nói với anh ấy rằng tài khoản của anh ấy đã bị tắt. Tôi không phải là kẻ yếu đuối. Chỉ là đôi khi tôi chưa đủ thô lỗ, dù điều đó nghe có vẻ buồn cười đến mức nào. Hãy giải quyết vấn đề này; giải quyết được một nửa có nghĩa là tôi chỉ cần kích hoạt của anh ấy và vô hiệu hóa của bạn ;-) Được chứ? Heh, đừng vô hiệu hóa tài khoản của miod, tôi vẫn thấy khó chịu với những tin nhắn cam kết tiếng anh hỏng hóc của anh ấy. và làm cách nào anh ấy có thể khắc phục điều này nếu tài khoản của anh ấy bị vô hiệu hóa? làm ơn ít nhất hãy để nó bật lên Giống như, DUH Bằng cách gửi cho bạn những khác biệt, đồ ngốc ôi. ờ. ở đó muộn rồi. Theo de Raadt đã bắn đầu tiên bằng cách vô hiệu hóa quyền truy cập của Murphree vào cây nguồn và gửi cho anh ấy email đó:
Ngày: Chủ Nhật, 16/12/2001 16:39:47 -0700 Từ: Theo de Raadt Kính gửi: Steve Murphree Cc: Miod Vallat Chủ đề: tài khoản Tôi đã vô hiệu hóa tài khoản của bạn vì tôi nghe nói bạn đang làm cvs vi phạm cây, vi phạm mã di động hoặc một phần di động, không làm việc tốt với những người khác, khiến các nhà phát triển khác đau buồn. Nhiều năm trước chúng tôi cũng phải huấn luyện Mickey theo cách tương tự. Tôi sẽ để bạn nói chuyện với miod về điều đó; anh ấy sẽ cho tôi biết khi nào nên kích hoạt lại nó. thật đấy bác... điều này quan trọng. Bạn không cam kết các phiên bản đã thay đổi của tệp 1.4 rev trên tệp 1.8 có các bản sửa lỗi khác. Đó chỉ là TUYỆT VỜI. Cuộc trò chuyện trong phòng chat tiếp tục bằng tin nhắn riêng tư sau đó.
thế này nhé, bạn thấy khỏe hơn chưa? chắc chắn sẽ giúp ích cho tôi rất nhiều. Hiện tại tôi đang viết tin nhắn cho Smurph... anh quyết định sẽ tử tế và chuẩn bị cho em bây giờ tôi khuyên bạn đừng chơi quá đẹp nếu bạn chơi quá đẹp, sau này anh ấy sẽ không nghe lời bạn đâu và thay vào đó tôi lại phải hét lên vì bạn lần sau tôi sẽ bảo bạn xuống địa ngục và sống chung với nó người tốt đã kết thúc cuối cùng. anh ấy cần bạn anh ấy sẽ không làm kỹ thuật phát hành với giá 88k nhưng tôi cá là bạn sẽ làm được vậy nên anh ấy phải thật sự tử tế với bạn hoặc những gì anh ta đang làm chỉ là một trò điên rồ và chúng tôi không chào đón những kẻ khốn nạn trong cây của chúng tôi được, được, được. Tôi không thích điều này nhưng tôi biết mình phải thô lỗ. Hãy xem cách giải quyết vấn đề này. Vì vậy tôi đã hoàn nguyên phần mvme88k của cây trở lại trạng thái ban đầu ngày trước.
Hoàn nguyên mvme88k về 20011212. Những thay đổi gần đây đã không được hợp nhất một cách chính xác, và tôi đã chán ngấy việc mổ xẻ những khác biệt để đặt lại mã đã biến mất. Điều này có thể sẽ được khắc phục trong thời gian ngắn.
Ngay sau đó tôi gửi bức thư này cho Murphree.
Ngày: CN, 16/12/2001 23:54:56 +0000 Đến từ: Miod Vallat Kính gửi: Steve Murphree Chủ đề: Re: tài khoản > Tôi đã vô hiệu hóa tài khoản của bạn vì tôi nghe nói bạn đang làm cvs > vi phạm cây, vi phạm mã di động hoặc một phần di động, không > làm việc tốt với những người khác, khiến các nhà phát triển khác đau buồn. > > Cách đây nhiều năm chúng tôi cũng phải huấn luyện Mickey theo cách tương tự. > > Tôi sẽ để bạn nói chuyện với miod về việc này; anh ấy sẽ cho tôi biết khi nào nên kích hoạt lại > Nó. > > thực sự đấy, anh bạn... điều này quan trọng đấy. Bạn không cam kết các phiên bản đã thay đổi của > tệp vòng quay 1.4 nằm trên tệp 1.8 có các bản sửa lỗi khác. Đó chỉ là > TUYỆT VỜI. > Được rồi, theo ý kiến của tôi thì Theo đã đi hơi quá xa, nhưng về cơ bản thì tôi nhận ra rằng bạn đã không dành chút thời gian để hợp nhất các điểm khác biệt của mình một cách chính xác và một số khác biệt đã biến mất không phải là tin tốt nhất vào cuối tuần. Bạn không tự tin với cv để thực hiện việc hợp nhất như vậy hay bạn hơi vội vàng? Bạn có cần giúp đỡ làm điều này? Dù sao đi nữa, tất cả những gì bạn cần là gửi một mã khác biệt với mã hiện tại điều đó không đưa các tập tin quay ngược thời gian, và tài khoản của bạn sẽ hoạt động trở lại bạn cam kết nó. Xin lỗi vì rắc rối, Miod Theo de Raadt không đồng ý với giọng điệu của bức thư đó và cho tôi những "gợi ý" về riêng tư.
xử lý anh ta? không có cc? Mình chưa cho bạn vào cc: muốn có một bản sao? chắc chắn rồi, để tôi xem bạn đã nói gì với anh ấy ;-) Tôi cá là bạn sẽ thấy tôi quá tử tế heh để tôi cho bạn một gợi ý khác nhé bắt đầu bằng câu "bạn đang giết tôi" thì hãy thay đổi nó Tôi luôn lắng nghe thay thế lời nói hết lần này đến lần khác haha cho đến khi bạn có điều gì đó vẫn nói "bạn đang giết tôi" mà không sử dụng những từ đó thực sự đôi khi tôi làm điều này ;-) đã trả lại tin nhắn cho bạn. QUÁ TUYỆT VỜI thở dài bạn chẳng học được gì cả. thấy không? đã nói với bạn. bạn đã làm được bao nhiêu giờ rồi chi tiêu trước khi bạn bỏ cuộc? cho tôi biết bao nhiêu giờ chết tiệt, đây là lần đầu tiên tôi làm điều này trong OpenBSD. Tôi được biết đến [sic] vì đã rất thô lỗ trong những tình huống như vậy trong công việc thực sự của tôi thôi nào, ước tính đi có bao nhiêu không thể nói được, tôi cũng đang làm việc với mã pmap mới của mình. 2 đến 4 giờ. chỉ 4 tiếng thôi à? bạn có nghiêm túc không? Tôi đã hoàn thành được 1/3 công việc làm lại. nghĩa là vẫn còn 8 giờ để làm việc này một cách chính xác. được rồi, gửi câu này đi. "Tôi đã dành 4 giờ để sửa các lỗi trong mã mà tôi không hiểu và tôi đã mong đợi còn lại tối thiểu 8 giờ. Trách nhiệm của bạn là không bắt tôi phải làm vậy cái này". gửi cái đó đi. ĐÓ là sự thật. không phải sự thật 100% sao? không, tôi hiểu mã. Đó chỉ là một PITA. nên nói như vậy. bạn cần phải lôi kéo anh ấy vào. liệu anh ấy có coi trọng bạn không? dù sao đi nữa, trận chiến của riêng bạn tạm biệt Phải mất vài ngày Murphree mới nguôi ngoai.
Ngày: Thứ Hai, 17/12/2001 09:12:39 +0000 Đến từ: Miod Vallat Kính gửi: Steve Murphree Chủ đề: Re: tài khoản > Chính xác thì tôi đã làm vỡ cái gì mà rắc rối thế này? Bạn đã gửi email cho tôi? làm ơn > kể cho tôi nghe những điều có thể khiến bạn khó chịu. Tôi không thể đọc được suy nghĩ. Không, tôi tìm hiểu > về việc Theo nói với tôi rằng tài khoản của tôi đã bị vô hiệu hóa. Đào. Bạn đã không làm vỡ đồ vật. Có vẻ như bạn chưa cập nhật cvs all the files, hence you commited changes to old revisions against -các sửa đổi hiện tại. Tôi dành vài giờ vào cuối tuần này để giải quyết conflicts and get your changes correctly merged in half of the files. Tôi đang định gửi cho bạn một bức thư về việc này. Sau đó tôi đã phạm sai lầm đề cập đến điều này trên icb, và Theo đã tỉnh táo. Và một khi anh ấy quyết định đóng tài khoản của bạn, dù tôi có nói gì đi nữa, tôi cũng không thể yêu cầu anh ta KHÔNG làm điều đó. > Hãy để tôi kể bạn đã làm gì: Bạn đã một tay lấy đi thứ gì đó > xa tôi mà tôi rất yêu quý. Một cái gì đó tôi rất tự hào. cảm nhận > tốt về nó? Tôi cầu nguyện không ai làm điều đó với bạn. Không ai xứng đáng với điều này. Bạn có nghĩ là tôi cũng thích điều này không? > Này, đừng hiểu lầm tôi. Tôi thích những việc bạn đã làm. Tôi tưởng bạn và > Tôi cũng nghĩ như vậy. Tôi thích có người khác quan tâm đến mvme88k > cổng. Tôi nghĩ đó là một điều tốt. Tôi thất vọng. Rất, rất > thất vọng. Tôi cũng tôn trọng công việc của bạn. Tôi không muốn mọi chuyện kết thúc như thế này tất cả. Bây giờ chúng ta hãy cùng giải quyết vấn đề này nhé? Miod Ngày: Thứ Hai, 17/12/2001 19:46:55 +0000 Đến từ: Miod Vallat Kính gửi: Theo de Raadt Chủ đề: tài khoản của Smurph Vâng, chúng tôi đã có một cuộc thảo luận dài qua thư về vấn đề này. Steve chắc chắn rất buồn đầu tiên, sau đó anh ấy bình tĩnh lại và chúng tôi thảo luận các vấn đề. Hóa ra anh ấy thừa nhận rằng anh ấy cũng đã cam kết thay đổi m88k của mình một chút sớm và đã lên kế hoạch khắc phục các sự cố hợp nhất sau đó một chút. Mặt khác tay, tôi thừa nhận rằng tôi đã quá khắt khe trong các thông điệp cam kết của mình, vì vậy điều này đã làm dù sao cũng không giúp ích được gì cho tình hình. Vì vậy kế hoạch hiện tại là anh ấy sẽ khắc phục những vấn đề hiện tại của ahc, cam kết những thay đổi cần thiết và sau đó cam kết lại các thay đổi mvme88k của anh ấy, nhưng đúng. Bây giờ bạn có thể kích hoạt lại tài khoản của anh ấy bất cứ lúc nào. Miod
Chúng tôi đã có cuộc trò chuyện riêng tư đó ngay sau đó.
Tôi vừa quay lại và trả lời tin nhắn của bạn Tối nay tôi sẽ cố gắng lấy lại những thứ đó. từng lớp một, vì vậy để nói. Có điều gì bạn thấy mà tôi có thể cần phải đề phòng không? nếu bạn có thể đảm bảo rằng GENERIC biên dịch, đó là một khởi đầu tốt. bạn đã kích hoạt lại tài khoản của mình chưa? Không cần đâu. Trừ khi bạn chỉ muốn. Tôi đã vượt qua nó theo như tôi nghĩ. Đó Tuy nhiên, mọi thứ đã tác động mạnh đến tôi. Nhưng ý tôi là những gì tôi đã nói về bạn và công việc của bạn. Bạn chính là người làm cho OpenBSD tốt hơn. […] vâng, Theo đã kích hoạt nó. vậy là cuối cùng cũng kết thúc rồi, tôi đoán vậy. Cảm ơn anh bạn. Bạn thật tử tế khi làm như vậy. Vâng, nó đã kết thúc. Tôi không chứa chấp mọi thứ. Tôi không giống mẹ tôi!! :) Bây giờ tôi đi ngủ (4:15 sáng), cul8r nhanh lên! Chúc ngủ ngon. (Mấy năm nay lịch ngủ của tôi thực sự rất lộn xộn. Nó đã thay đổi rất nhiều kể từ đó vậy, và nếu hôm nay bạn thấy tôi thức dậy lúc 4:15 sáng thì đó là vì tôi vừa mới tỉnh dậy đi, không phải vì tôi sắp bị ngã...)
Murphree chia những thay đổi của mình thành những phần nhỏ hơn và đảm bảo không bỏ đi. những thay đổi hiện có vào thời điểm này, bắt đầu từ ngày 19.
Ngày: Thứ Tư, 19/12/2001 09:21:46 +0000 Đến từ: Miod Vallat Kính gửi: Steve Murphree Chủ đề: Re: CVS: cvs.openbsd.org: src > CVSROOT: /cvs > Tên mô-đun: src > Thay đổi bởi: smurph@cvs.openbsd.org 19/12/2001 00:04:42 > > Tập tin đã sửa đổi: > sys/arch/mvme88k/conf: CHUNG M187 M188 M197 > sys/arch/mvme88k/dev: bussw.c cl.c clock.c Dart.c mainbus.c > nvram.c pcctwo.c sram.c syscon.c vx.c > sys/arch/mvme88k/bao gồm: cpu_number.h cpus.h param.h > sys/arch/mvme88k/mvme88k: cmmu.c eh.S locore.S > locore_c_routines.c m18x_cmmu.c > machdep.c pmap.c pmap_table.c > > Thông điệp tường trình: > Giới thiệu brdtyp và thay đổi ý nghĩa của cputyp. Bạn biết đấy, tôi thích việc bạn thực hiện điều này ở một số phần. Nó giúp biết tại sao mỗi tập tin được bị ảnh hưởng và cung cấp khả năng, trong trường hợp có vấn đề, dễ dàng tìm thấy các bản sửa đổi ổn định hơn. Miod Khi sự căng thẳng được giải quyết và cây nguồn trở lại trạng thái tốt, đã đến lúc để bắt đầu giải quyết vấn đề chính trước mắt: trình biên dịch.
Ngày: Thứ năm, 27/12/2001 00:50:55 +0000 Đến từ: Miod Vallat Kính gửi: Steve Murphree Chủ đề: kernel mvme88k gcc 2.95 chưa hoạt động... Chà, cuối cùng tôi đã có thể biên dịch và liên kết một hạt nhân trên một sparc. Nhưng, bằng cách nào đó, tôi nghĩ vẫn còn một chặng đường dài phía trước: 187-Bug>BO 6 0 gcc295 Khởi động từ: VME328, Bộ điều khiển 6, Ổ 0 Đang tải: gcc295 Khối lượng: M88K IPL được nạp vào lúc: $009F0000 Khởi động: thiết bị lỗi: ctrl=6, dev=0 bootxx: bootstrap cấp độ đầu tiên chương trình [$Bản sửa đổi: 1,1 $] \ >> OpenBSD/mvme88k bootd [$Bản sửa đổi: 1,2 $] 1769472+147456+205664+[68940+80842]=0x22ac7a Bắt đầu @ 0x10020 ... Địa chỉ người kiểm soát @ ffff9000 ... Cấu hình bo mạch MVME187 #A: 1 CPU 2 CMMU CPU0 được gắn với 2 MCMU MC88200 CPU0 là CPU chủ [sử dụng 149782 byte của bảng ký hiệu bsd a.out] Bản quyền (c) 1982, 1986, 1989, 1991, 1993 Các nhà quản lý của Đại học California. Mọi quyền được bảo lưu. Bản quyền (c) 1995-2001 OpenBSD. Mọi quyền được bảo lưu. http://www.OpenBSD.org hoảng loạn: xác nhận chẩn đoán kernel "(align & (align - 1)) == 0" không thành công: tệp "/src/current/src/sys/arch/mvme88k/compile/M187/../../../../uvm/uvm_map.c", dòng 843 Đã dừng ở _Debugger: tb0 0x0, r0 ,0x84 CHẠY ÍT NHẤT 'dấu vết' VÀ 'ps' VÀ BAO GỒM ĐẦU RA KHI BÁO CÁO NỀN TẢNG NÀY! KHÔNG BAO GIỜ BÁO CÁO ĐIỀU NÀY MÀ KHÔNG CÓ BAO GỒM THÔNG TIN ĐÓ! ddb> dấu vết cơ sở ngăn xếp = 0xeee07d80 (0) _Trình gỡ lỗi (không có ngăn xếp) (1) _panic+0x138(?, 14f640, 0x150558, 14fef0, 34b, 0xffffffff, 0xffffffff, 0xff ffffff) (2) ___assert+0x2c (3) _uvm_map_findspace+0x5c (4) _uvm_map+0x184 (5) _uvm_km_init+0x118 (6) _uvm_init+0x60 (7) _chính+0x68 (8) master_start+0x64 ddb> Đó là một sự khởi đầu... Tuy nhiên, tôi không dành nhiều thời gian cho việc này và luôn bận rộn với những việc khác. Các hoạt động của OpenBSD. Tuy nhiên, cuối cùng tôi đã có thể xây dựng được gần như vùng đất người dùng hoàn chỉnh để chúng tôi có thể có sẵn nhiều tệp nhị phân gần đây hơn nhị phân 2,5 cũ.
Ngày: Thứ ba, 7 tháng 5 năm 2002 23:08:32 +0000 Đến từ: Miod Vallat Kính gửi: Paul Weissmann, Steve Murphree Chủ đề: tin tức mvme88k Chà, tôi đã cập nhật trang trạng thái mvme88k của mình và có một trang chưa hoàn chỉnh, nhưng đang hoạt động, ảnh chụp nhanh 3.1-beta. Tuy nhiên, không có bsd.rd để cài đặt chống lại các vấn đề về chuỗi công cụ. http://XXX.XXX.XXX.XXX/~miod/mvme88k Miod Tháng 8 năm đó tôi có cơ hội nhận thêm phần cứng mvme88k, bao gồm bảng MVME197LE; Tôi cũng có trong tay một số thông tin sai sót, có thể tìm thấy (trong số các tài liệu khác chưa có trên bitavers) trên trang này.
Ngày: Thứ bảy, 17 tháng 8 năm 2002 22:21:23 +0000 Đến từ: Miod Vallat Kính gửi: Steve Murphree Chủ đề: mvme 197 lỗi Xin chào, Tôi có một tài liệu 20 trang ở đây. Nó chứa: "MVME197 LỖI" phiên bản 1.10, 24/3/94 "MVME197DP/SP LỖI" phiên bản 1.0, 17/3/94 Gói tài liệu lỗi 88110 Rev 4.2 (3E34M), Phiên bản 1.6, 15/9/93 Gói tài liệu lỗi 88110 Rev 5.1 (2E66S), Phiên bản 1.0, 15/9/93 Đây có phải là cái bạn có không? Bạn có muốn một bản sao của tài liệu này? Trích đoạn: 1) LỖI: Việc truyền dòng do VMEchip2 thực hiện có thể khóa bảng. 2) LỖI: Xung đột với DCAM2 trong các chu kỳ vô hiệu. 3) LỖI: Bus nối tiếp I2C không đầy đủ chức năng 4) LỖI: Ánh xạ nô lệ VMEbus 5) LỖI: Các thanh ghi BusSwitch ISEL có đường dẫn ghi dữ liệu bị đảo ngược. 6) LỖI: vấn đề sd/ld.x với 88110 7) LỖI: Thiết lập lại cục bộ không hoạt động đúng 8) LỖI: Thực thi lệnh XMEM cho VMEbus Slave không khóa được xe buýt. Một số trong số chúng đã được cố định trên các bảng gần đây, tôi cũng có lịch sử của Sửa đổi PCB, v.v. Tôi cần sắp xếp việc này và cung cấp cho bạn nhiều hơn chi tiết. Miod Trong khi đó, Marc Zyngier của Linux nổi tiếng đã có được một chiếc máy MVME188 4 bộ xử lý và hỏi tôi liệu OpenBSD có thể chạy trên nó không.
Ngày: CN, 5/1/2003 23:19:54 +0000 Đến từ: Miod Vallat Tới: Marc Zyngier Chủ đề: MVME188 Bon, j'ai testé mes cartes MVME188{,A} cet après-midi, et comme par hasard, le support MVME188 a été cassé par les cam kết kiểm duyệt aporter le support MVME197 (qui n'a jamais Marché chez moi...). De longues heures de déboguage và quan điểm. [Vì vậy, tôi đã thử nghiệm các bo mạch MVME188{,A} của mình vào chiều nay và thật ngạc nhiên, hóa ra sự hỗ trợ MVME188 đã bị phá vỡ bởi những thay đổi được cho là sẽ mang lại Hỗ trợ MVME197 (chưa bao giờ hoạt động ở đây...). tôi đang mong đợi nhiều giờ gỡ lỗi.] Ngược lại, en triant mes HYPERmodule, j'ai vu que j'avais un mignon 4P128 (4 CPU, 8 CMMU) à 25 MHz, mới hơn. Faudra vraiment que je bosse trên SMP một ngày. Un MVME188A với 4P128 ne tiendra pas la Route Đối mặt với MVME197DP à 50 MHz, có lẽ bạn sẽ có nhiều cơ hội hơn 188 tourne à nouveau avant que le 197 tourne tout sân... [Tuy nhiên, trong khi sắp xếp HYPERmodule của tôi, tôi nhận thấy rằng tôi có một 25 MHz 4P128 (4 CPU, 8 CMMU). Sẽ phải làm việc trên SMP vào một lúc nào đó điểm. 4P128 MVME188A sẽ không thắng được MVME197DP 50 MHz, nhưng rất có thể sẽ được chạy lại trước khi có 197 lần chạy...] Miod Tuy nhiên, giống như cuộc điều tra hành vi gcc 2.95, điều này không trở thành bất cứ điều gì: trên bo mạch MVME188, kernel sẽ khởi động nhưng không bao giờ khởi động init, và tôi đã từ bỏ khá nhanh chóng.
Mọi thứ có vẻ tồi tệ đối với cổng đó và việc thiếu chuỗi công cụ trong cây, ngày của nó bây giờ đã được đánh số.
(Theo liên kết này để chuyển sang phần tiếp theo.)
Tác giả: rbanffy
- MVME187
-
MVME180 và MVME181