@walkero I have guessed that but the GPL is clear that if you distribute binaries containing any GPL source you should also include the license text and a way to get the sources of the binary (a link is enough). So if I have such binary and find a problem I can look at the source to debug and fix it even if the original author is gone or can't fix it. If I later distribute such fixed or modified binary I should also pass on the source changes so others can improve it further. That's what open source is about and that's what the GPL is meant to ensure legally turning around the licenses commercial companies are using to take away those freedoms from you. That's why it's called copyleft instead of copyright.
That only happens thanks to Derfs's opensource scsi skeleton driver which were srarting point, then big help from Georg and Balaton and others together with all the testers. Without discussing issues with anyone its always less fun ..
And most importantly the Linux driver sources which was even bigger help that you could use thanks to the GPL otherwise these were probably already lost or locked up like the CFE sources which has a less restrictive license that allowed people to make changes without publishing the source. So keep it going making sure the sources won't get lost and others can help you to maintain and improve the driver further by complying to the GPL.
I hope people who sit on firmware sources and AmigaOS parts realise it would be better to make these copyleft and use the help of people who could help improving it instead of just trying to do something using an AI that they hope they could sell for a few bucks. It would not reach anywhere near modern OSes that way and it would just die out with them unless they share what they have. For things that were made using GPL code like U-Boot sources for A-Eon machines or SCSI drivers it's not even a question that they have to publish the source if they distribute binaries.
@kas1e If CFE was GPL you now would not have to disassemble it and do a lot of work to fix problems with it. If Linux was not GPL you would have had to write the PA6T driver from scratch without documentation. That's why you should respect GPL and make sure to keep the sources with the binaries to make the life of people easier who come after you and want to improve it further. In the end that may also help you because then you'll also get those fixes and enhancements too thanks to the GPL. If you write something from scratch it's up to you what you do with it, you can keep it or give it away for free or only give it to those who pay you but if you build on GPL sources you have to respect the decision of people before you who said you can use it for free as long as you also do the same and make the sources available of what you build with the sources. This saves a lot of work for you but you should also do the same for the others in exchange. And that's as easy as always linking to the source and include the license with the binaries.
For things that were made using GPL code like U-Boot sources for A-Eon machines or SCSI drivers it's not even a question that they have to publish the source if they distribute binaries.
Which SCSI driver are you referring to? The driver for the Classic Amiga/WinUAE CyberStormPPC onboard SCSI controller, cybppc.device.kmod, was implemented by the NetBSD Amiga/m68k maintainer, with a little help from me for the AmigaOS 4.x/PPC specific parts, based on the NetBSD Amiga/m68k driver for it. BSD licence, no GPL. The PCI NCR/SYM/LSI SCSI driver from sg2, lsi53c8xx.device.kmod, was implemented by him from scratch, without using any BSD nor Linux code.
Which SCSI driver are you referring to? ... The PCI NCR/SYM/LSI SCSI driver from sg2, lsi53c8xx.device.kmod, was implemented by him from scratch, without using any BSD nor Linux code.
The lsi53c8xx one. No BSD or Linux code but U-Boot which is also GPL. How do I know? QEMU emulates this SCSI controller which I've tried and there are two drivers that don't work with it. U-Boot and this AmigaOS driver and they both seem to poke the same registers the same way. Then looked at Documentation/IDE/lsi53c8xx_dev.doc which says: "If UBoot can see your drives then the driver should too." That's enough proof to me to think U-Boot code was used for it and therefore it should have been open source. BSD allows using it in closed source stuff so that is not a problem to copy code from there but GPL explicitly only allows it to be used in open source projects for a reason to promote open source.
The lsi53c8xx one. No BSD or Linux code but U-Boot which is also GPL. How do I know? QEMU emulates this SCSI controller which I've tried and there are two drivers that don't work with it. U-Boot and this AmigaOS driver and they both seem to poke the same registers the same way. Then looked at Documentation/IDE/lsi53c8xx_dev.doc which says: "If UBoot can see your drives then the driver should too." That's enough proof to me to think U-Boot code was used for it and therefore it should have been open source.
If the U-Boot lsi53c8xx driver doesn't work with QEmu's emulation of the NCR/LSI/SYM 53c8xx the Linux(PPC) driver, using an old Linux version from the same time, probably doesn't work either because of
[...]
* partly derived from
* linux/drivers/scsi/sym53c8xx.c
Did you test that?
If 2 independently developed drivers for the same hardware don't work on QEmu it's more likely a bug in the QEmu emulation than different drivers having the same bugs.
@joerg AFAIK Linux drivers work but I did not test much as it's probably better to write a virtio-scsi driver for AmigaOS instead than trying to fix this device emulation. I just tested it to see if it worked and it was any better than the IDE emulation that already works. Quote:
If 2 independently developed drivers for the same hardware don't work on QEmu it's more likely a bug in the QEmu emulation than different drivers having the same bugs.
It's surely something not emulated in QEMU that these drivers hit but the point is that if two drivers hit the same bug while other's don't then it's likely these drivers have similar code.
Just wanted to report that I have nothing to report
I've been using your new pa6t_eth on my X1000 24/7 since I installed it, I believe on the 27th of March. I did reboot a few times during that period, but for other reasons, I have seen no problems that looked like they were caused by the Ethernet driver. Right now my uptime is 1 day and almost 17 hours.
I've been browsing, downloading all sizes of files, uploading stuff to my LAN drive and web server and in short done all my normal activities.
So good job, one more limitation blown away from the X1000.
It's surely something not emulated in QEMU that these drivers hit but the point is that if two drivers hit the same bug while other's don't then it's likely these drivers have similar code.
Similar, probably, but still different. For example the AmigaOS 4.x driver supports more variants of the NCR/SYM/LSI 53c8xx than the U-Boot driver does. The "If UBoot can see your drives then the driver should too." in the docs just refers to 2 things: - The AmigaOS 4.x driver supports all 53c8xx versions the U-Boot driver does (and some additional ones U-Boot doesn't). - Both the U-Boot and the AmigaOS 4.x drivers use the same ENV variables for it's config.
I have been using this for a few days now and it seems to work well and also faster than the rtl8139.device.
I have however noticed one issue.
If I do a soft reboot the onboard serial device does mot run and I get a Network Log Output window with the message:
Sat Apr 11 11:38:46 2026 [error]: Could not open "pa6t_eth.device" unit 0 (-1, Device/unit failed to open).
If I do another soft reboot all is fine again and the pa6t_eth device works again. Another reboot and I get the message again, then another and it works again.
@BillE same here, I dont have a serial connection, but to have working network I have to soft reboot twice, but since Radeon RX doesn't support soft reboot and my intention is to switch to Radeon RX when the vga_fix is stable I doesn't told it. Hard reset seems to work every time
@BilliE That x1000 motheboard issue : me and some others have it too. I.e. x1000 not on every boot enable physically onboard network. You can detect it by led in your router : simple sometime x1000 didnt enable it. It can be, of course, another bug in CFE.
Edit: so pvanni's x1000 is another one.. you can check led on router to which x1000 connected. It just 50/50 enables on boot. If not everyone have it by some , then there should be some different motherboard revissions or some specific configs.
@pvanni Quote:
Hard reset seems to work every time
Not for me.. for me it 1 time network led enables on boot, on second not. Rare it enables for 2 resets in a row. Some time i even need 3 resets (because my one offten stuck on dram check too)
Sounds like something is wrong in your AddResetCallback() function for resetting the device to an usable state for a reboot.
No no, you got it wrong. That absolutely WITHOUT any driver, and without OS4 : simple power on X1000, go to CFE, check the light led of the network : 50% of times it died. Doing reset, and it up.
That on lowlevel, just poweron + CFE, no OS or my driver involved.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
