I will try but I haven't got any serial cable for the X1000 (AmigaKit seems to sell one which can connect to tne internal serial port).
@NBache
Where do you type these lines?
Quote:
SPEED=set pmu -astate=a0; set astate 4 -speed=1800; set pmu -astate=a4 SPEED2=set pmu -astate=a0; set astate 4 -speed=2000; set pmu -astate=a4 STARTUP=SPEED2; menu
I tried to enter them like this with CFE command line and I only get: "invalid command SPEED"
-- AmigaONE X1000 and Radeon RX 560 Sam460 and Radeon RX 560 MiST FPGA Replay + 060 DB
@Sailor,TearsOFMe In meantime i fix those 3 bugs (can't dir/boot from channel1 (port, port3), crash when 2 gfx cards in, and non ability to boot form cd after patch is applied), but not released it today because found something interesting in another topic about how amigaboot.of works (and probably not only, but probably linux too) : to find the device from which amigaboot can boot, amigaboot.of scan for "block" devices in the OF dev tree. For USB there is no child created for, so amigaboot.of can't find it => can't boot => no bootable partition found. But same issue share my Sata fix too! YEs, i add support for channel, and make all devices showup and be able to be listed by dir, etc, but they will not boot in the sense of usual amigaboot.of , because i didn't add them as "block" devices into OF tree.
So, now i need to sort out how i can add devices to the OF tree, then it will mean i will fix not only sata, but USB boots too, so stay tuned !
kas1e wrote:@Sailor,TearsOFMe In meantime i fix those 3 bugs (can't dir/boot from channel1 (port, port3), crash when 2 gfx cards in, and non ability to boot form cd after patch is applied), but not released it today because found something interesting in another topic about how amigaboot.of works (and probably not only, but probably linux too) : to find the device from which amigaboot can boot, amigaboot.of scan for "block" devices in the OF dev tree. For USB there is no child created for, so amigaboot.of can't find it => can't boot => no bootable partition found. But same issue share my Sata fix too! YEs, i add support for channel, and make all devices showup and be able to be listed by dir, etc, but they will not boot in the sense of usual amigaboot.of , because i didn't add them as "block" devices into OF tree.
So, now i need to sort out how i can add devices to the OF tree, then it will mean i will fix not only sata, but USB boots too, so stay tuned !
It sounds very good - both SATA and USB, thank you for effort!
AmigaOS3: Amiga 1200 AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000 MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
Quote: SPEED=set pmu -astate=a0; set astate 4 -speed=1800; set pmu -astate=a4 SPEED2=set pmu -astate=a0; set astate 4 -speed=2000; set pmu -astate=a4 STARTUP=SPEED2; menu
I don't. These lines are the listing of the already set env variables (listed with "printenv" in the CFE command line).
To set them, you must use e.g.:
setenv -p SPEED 'set pmu -astate=a0; set astate 4 -speed=1800; set pmu -astate=a4'
and similar for the other two. (The "-p" means save the variable permanently, if you omit the "-p", you will just set the variable temporarily, e.g. if you want to test it, then it reverts to the previously saved value when you restart.)
BTW, I use a Radeon HD card, so I can do everyting locally in the CFE prompt and don't need to go via the serial link.
found something interesting in another topic about how amigaboot.of works (and probably not only, but probably linux too) : to find the device from which amigaboot can boot, amigaboot.of scan for "block" devices in the OF dev tree. For USB there is no child created for, so amigaboot.of can't find it => can't boot => no bootable partition found. But same issue share my Sata fix too! YEs, i add support for channel, and make all devices showup and be able to be listed by dir, etc, but they will not boot in the sense of usual amigaboot.of , because i didn't add them as "block" devices into OF tree.
So, now i need to sort out how i can add devices to the OF tree, then it will mean i will fix not only sata, but USB boots too, so stay tuned !
That's not enough. It also needs the seek and read words/methods to work on that device node as amigaboot.of calls back to those to access the disk. Basically amigaboot.of needs a block device that it can read sectors from to be able to try to read the filesystem on it and load files from it. It has no disk drivers but calls back to the firmware for it. On U-Boot systems this is hacked in U-Boot by the Friedens and everybody copied their patches ever since on Sam and AEon machines that have U-Boot. This adds a non-standard call-back system to U-Boot just for amigaboot even though U-Boot has it's own client interface (maybe it did not have that back then). On OF compatible systems amigaboot.of uses the client interface calls to discover device tree and the interpret command to call methods on device tree nodes.
I just go easy way for now, i simple attach hdd to port0 (the one which CFE's devtree see at startup as block device), then find out where all pointers/siblings are to next nodes, create new node (based on diag dump from exiting one), and simple copy only one things from ide0.0 node - method dispatch pointer so which handle open/read/seek/close, and damn , it works ! I have update the devtree, and booting from atapi1.0 by amigaboot works !!!
Now, that when we have something from which i can copy. But then, if i want simple channel1 (so nothing in devtree to copy from). Then , its CFE and addresses hardcoded with every this versions on all x1000, so i simple take it's address (i mean this pointer to methods) , and put it for my node when create one from scratch, and it WORKS !!! I mean it start booting ! Crashes with MCE after all modules loads up, but that probably something about kernel and my dirty tricks, will see..
[pci@12]
| name str 'pci'
| device_type str 'pci'
| vendor-id val 0x00001002
| device-id val 0x00004380
| revision-id val 0x00000000
| class-code val 0x0001018F
....snip...
| interrupt-parent val 0x7FE2C8E8
| interrupts cell 000000D4 00000001
[ide0.0]
| name str 'ide0.0'
| device_type str 'block'
[atapi0.1]
| name str 'atapi0.1'
| device_type str 'block'
[ide1.0]
| name str 'ide1.0'
| device_type str 'block'
[ide1.1]
| name str 'ide1.1'
| device_type str 'block'
Anyway, now, i only need to understand, if this "method" of open/read/seek/close can be used for USB stick or i have to create new one with specific read/seek/etc.. But at least this method surely works for atapi and hdd.
Edited by kas1e on 2026/4/12 17:28:23 Edited by kas1e on 2026/4/12 17:28:46
@kas1e If you're lucky and the method implementations call into some high level block device layer and not in low level drivers directly they could work for USB too unless this is the API layer that different devices have to implement in a device specific way. But if CFE can load stuff from USB there's somewhere an implementation for these that only need to be hooked to the device tree methods.
That the hardest part. Because some users for sure can't risk to have a brick. This need careful planning and testing-retesting.
At this point your other flashing thread would have been better to bring this up.
Looking at the TRM it lists the EEPROM as 24LC128 which still looks common. Board image is a but blurry or pixelated up close but looks like chip is soldered on board.
Quote:
Imho even with bad reflashing CH341A should help without replacing chips (it have some clips you attach right on top of chip without needs of resolder it, so to read/write data to).
Yes that would be useful. The mini kit I bought on eBay included a SOIC clip. Popular for BIOS flashes and the advice is generally to isolate it if possible, as the CH341A provides power to the chip, so still being connected to motherboard circuitry can be risky and interfere with operation.
Quote:
Ahah :) At least, i should't post exactly self-explained full details of how things done, so he can't copy it saying that he do it all : ) But , seeing how SSolie working on X5000 firmware, and how he for 2 or more years wasn't able to simple compile it , i have big doubts anything will be out from them ever if they will not change the managment/devs/etc. But who care, we can do it our way.
Going by the speech, he has the source, but not the compiler setup. So the source is most important, but it would have helped to have a HDD image of the work station. It's an old story really; can't compile old code in compiler. In a world of VMs and dockers, containers and what not this shouldn't be an issue. He should have been given an image of the whole system. In the least a toolchain he could easily compile.
To cut a long story short or trying to here, a friend gave me a DLink DIR850 router, new in box. The internet changed at home so main router was moved to kitchen. I wanted to repurpose it as a client for my X1000. I found there was some hidden support for a client mode, but only for some model variants, such as Singapore firmware. So what I did was download the source when I discovered the DLink server. I found Dlink is very good with their sources, as the source includes the toolchain needed to compile. Where I'm getting at is at this point, the workstation system they used was already ten years old, an older 32 bit system running Fedora IIRC. I installed it into a folder and set to work. For the most part the toolchain was able to configure fine and compile tools needed to build. Then it got stuck, when some binaries compiled to 32 bit broke on my 64 bit Linux. I just deleted them and they recompiled. So, in this case, I had it easy. I could then go ahead with some firmware hacking. But, Solie isn't a hacker like me, he's an experienced developer. So, if he got stuck, then the sources must really need a particular setup that's hard to update. I know from a little experience how annoying compiling older sources using a newer compiler can be.
UBoot? Wow did you compile it as a client? ISTR UBoot having some sort of boot mode where it can be booted as a client program.
I found something on my laptop and tracked down the source. Literally. There's some initial UBoot port to the PA6T. What's interesting is it includes sources for building an OF tree. Did they take this out and use it? Have you seen it before?
My command line is : setenv -p STARTUP 'speed ; setenv os4_bootdevice "auto" ; boot -fs=amigafs ide0.0:amigaboot.of'
Was that to set the variables? That's not executed on each boot? As that wouldn't be good on each boot, if it did that, as it would be permanently saving a variable to NVRAM on each boot.
On U-Boot systems this is hacked in U-Boot by the Friedens and everybody copied their patches ever since on Sam and AEon machines that have U-Boot. This adds a non-standard call-back system to U-Boot just for amigaboot even though U-Boot has it's own client interface (maybe it did not have that back then).
That's interesting, as in Uboot, at the least the A1/Sam one loading SLB lists USB as a boot source. It doesn't even need to be checked from boot code. If code is booted off USB, then the current device will be set to USB drive, and can transparently read blocks from the device handle.
Quote:
If you're lucky and the method implementations call into some high level block device layer and not in low level drivers directly they could work for USB too unless this is the API layer that different devices have to implement in a device specific way. But if CFE can load stuff from USB there's somewhere an implementation for these that only need to be hooked to the device tree methods.
Lucky yes. I would have expected it to have hardware drivers internally since it it needs to program USB. I suspect this is a bit like my ELF questioning, where the USB loading logic is in there, but not exposed in the client interface and hidden away in the CFE internals clients can't see.
- fixed: 2 gfx cards at once cause a crash, caused by hardcoded BARx addresses, no proper scanning. - fixed: can't boot from real ISO when patch enabled : by ancident enable UDMA for Atapi also, which can't work of course. - fixed: can't boot/dir from ide1.0 and ide1.1, was because of wrong UDMA handler of channel1 - changed: now all output go to serial too, and not just to console. - all the devices added to the devtree and amigaboot can find them as bootable devices as well.
@TearsOfMe Were you able to boot fine without path installed in the same config ? I just currently tested in 5 different cases, and were able to boot and from CD , and from HDD, and from CD alone, and when CD with HDD, etc. Maybe you have older RadeonHD driver on your install CD while have RadeonRX or something of that sort ? Or mixing bug of all patches, etc.
Try it clean, just this patch, so if bug will be there i can reproduce it.
Okay maybe it was not loaded correct on my first try. Had no serial attached. Now I start without the SATA fix and then load on CFE the fix. Now it stalls by loading it. File:sata_fix.elf Options:(null) Loading: 0x0000000000100000/11224 0x0000000000102BD8/2753 0x0000000000103699/43 Entry at 0x0000000000100000 Starting program at 0x00000000001021:53:43.671 000021:53:43.830 [RUN!]=== SATA FIX v22 ===
Both channels + dynamic BARs + 21:53:44.035 ATAPI + UDMA
@TearsOfMe Something very wrong somewhere.. You need power off, then plain boot, etc. And try with serial of course, that may give more info, but if you on radeonhd then console should work too ..
Step 4a: Channel 0 -- boot already found both, skipped
Step 4b: Probing Channel 1 (BAR2)...
P1+PD applied (BAR2, instance 1, master present)
IDE unit 0: Disk, "OCZ-AGILITY3", Capacity:55GB (lba48)
IDE unit 1: Disk, "Intenso SSD SATAIII", Capacity:447GB (lba48)
PCIIDE: 2 controllers found
Ch1 probe returned!
Its like you already run it first time, and run it again.. Or some older/previos version were running.. In any case, try this : no other patches, radeonHD and only this single patch. If all will works as expected then we will going further
@All Have a good progress : can boot from USB ! I tried to fix also "autodetection" when stick already in after boot, but that turns out to be 2 more seconds on enumeration of USBs , so kind of suck. Probably worth to keep it as it, just a hook on "when usb stick is inserted". So it will be all the same as it now, just when you will insert usb stick it will create a node in dev tree with correct methods and be able to boot from.
I just didn't see i good way how to detect that USB stick already in without probing all usb ports again .. Any ideas ?
Edited by kas1e on 2026/4/12 21:37:23 Edited by kas1e on 2026/4/13 4:27:21
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
