Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - kerravon

Pages: [1] 2 3 4
1
Programming / Re: FAT32 vs FAT16
« on: March 20, 2024, 04:01:40 pm »

You seem to be convinced that this is a FAT16/FAT32 problem. If it is, then changing the '06' to '0C' should fix it. Have you tried that? I'd be really, really amazed if it did because LVM doesn't care what filesystem is in use. It cares about whether the partition's start/end/size look valid and whether the corresponding DLAT info is present and valid. And from what you say, it isn't.


I think that's a very harsh behavior for lvm to do, if that's really expected.

It's very normal to import a disk from another site - that is not OS/2/LVM-aware, and it is wrong to say that the partition is corrupt. It's merely lacking LVM info - very normal and expected, and misleading to call it corrupt.

I believe the FAT32 behavior is correct - no complaints about the partition.

Also note that even though the FAT16 disk is reported as corrupt, it is accepted anyway.

2
Programming / Re: FAT32 vs FAT16
« on: March 20, 2024, 03:57:02 pm »

Whereas the following is accepted and lvmgui does complain

  80 04 01 00 0C 03 D1 C4 44 00 00 00 20 00 02 00

DOESN'T complain.

You might like to attach the two VHD here, as they compress well, being empty.

This forum accepts attachments.

3
Programming / Re: new gcc toolchain
« on: March 17, 2024, 09:03:54 am »

parted mkpart 0x80,0x06,63,954513 pdos.vhd
mkdosfs --blocks 477256 --offset 63 -F 16 -n "PDOS" pdos.vhd
mcopy -i pdos.vhd --offset 63 hi.txt ::


BTW, all the above tools, and almost all the source code on the PDOS/386 disks - is C90 compliant and thus should compile on basically any C compiler, including the gcc 3.2.3 that I ship as LX executables.

I simply haven't constructed a makefile and executed the makefile to build them.

That is basically an exercise for the reader.

I have stopped at the point where all the essential tools to do a C90 compile have been built.

So using nothing more than either base OS/2 plus the tools on the PDOS/386 disk - or just PDOS/386 itself - you should be able to reconstruct the world armed with a C90 compiler and a masm-subset assembler.

4
Programming / Re: new gcc toolchain
« on: March 17, 2024, 08:58:47 am »
I switched from FAT32 to FAT16 in order to test that, and managed to crash ArcaOS 5.0.8 attempting to add the attached volume. I will report it via the official channels.

Did you change the partition type?

Yes, 06 for FAT16.

Created like this:

D:\scratch\xxx>type doit.bat
del pdos.vhd
parted mkpart 0x80,0x06,63,954513 pdos.vhd
mkdosfs --blocks 477256 --offset 63 -F 16 -n "PDOS" pdos.vhd
mcopy -i pdos.vhd --offset 63 hi.txt ::

D:\scratch\xxx>


Bug report:

https://mantis.arcanoae.com/view.php?id=3616

5
Programming / Re: new gcc toolchain
« on: March 17, 2024, 08:14:49 am »
I switched from FAT32 to FAT16 in order to test that, and managed to crash ArcaOS 5.0.8 attempting to add the attached volume. I will report it via the official channels.

6
Programming / Re: new gcc toolchain
« on: March 17, 2024, 02:10:25 am »

I think I have misdiagnosed and it is parted that is wrong.

That's supposed to be number of sectors, not end LBA.

Will get back when confirmed.

A hell of a ride.

Both Robert and I had confusion/misunderstandings about different things and that caused numerous emails back and forth, each insisting the numbers proved something the other wouldn't accept.

So when I saw in Wikipedia that the last value was meant to be a count, not the end LBA address - and having previously calculated that the end CHS matched the end LBA which made me think parted was correct - I was confident that the sector count was wrong, and the end CHS was likely correct.

Turns out that it was a correct count all along, and that the end CHS had similarly been implemented as an "offset" rather than an absolute value, and Robert believed that was exactly what it was meant to be, and insisted the values all matched. And furthermore, Windows and Linux didn't have a problem either. But they don't use those CHS values, so that's not a fair test. And furthermore, Windows doesn't seem to bother setting them to reasonable values, relying on the fact that they are supposed to be ignored in type x'0c'.

We had to go right back to MSDOS to confirm the behavior as "definitive", and then Robert made the required code change.

This was combined with inconsistent behavior from ArcaOS. It seems that the start CHS can be arbitrary, but the end CHS should be maxed out in the last cylinder. But ArcaOS doesn't strictly enforce that. So when I was making adjustments, and it worked, I would form a conclusion, but then have that conclusion invalidated by another test.

However, I eventually got it to work, and now there is a pdoso.zip that starts on sector 504, so I'm only wasting 230k or 200k depending on how you count (63 vs 128) in order to get both track alignment and 4k alignment.

In addition to that, pdoso.zip was updated with a new pdld so that ArcaOS can build ELF executables if that is useful for some reason. It won't run them though. You have to run them on PDOS/386 (either pdos.zip or pdoso.zip) or real Linux.

I'm expecting to now switch to replicating for Linux what I have just done for OS/2.

7
Programming / Re: new gcc toolchain
« on: March 16, 2024, 06:18:15 pm »
Unrelated to the previous message, I have (hopefully temporarily) given up 4k alignment to produce a pdoso.zip that is acceptable to ArcaOS. Available at pdos.org

And independent of that, there is now ELF support under PDOS/386 via makefile.lnp (pdos.zip not pdoso.zip) which will hopefully evolve to be the same as pdoso.zip for OS/2.


8
Programming / Re: new gcc toolchain
« on: March 16, 2024, 05:34:53 pm »

So there's the ArcaOS bug - unless I have misdiagnosed.


I think I have misdiagnosed and it is parted that is wrong.

That's supposed to be number of sectors, not end LBA.

Will get back when confirmed.

9
Programming / Re: new gcc toolchain
« on: March 16, 2024, 12:14:07 pm »
Before I am looking deeper into it, I have a question:

How does this toolchain handle debugsymbols?

If I was to compile something with gcc -g ... do the debugsymbols end up in the exe file? If so, then what type of debugsymbols and is there a debugger on OS/2 that is compatible with those?

Sorry - this is just meant to be a starter system.

I don't think there is any debugging capability. I always use printfs to debug. Except when there is a crash and I get the EIP and match it to the link map and assembler listings, and I read the assembler code and match it to the C code.

And I'm always doing optimized compiles where debugging isn't available anyway as far as I know.

10
Programming / Re: new gcc toolchain
« on: March 16, 2024, 12:10:39 pm »
Next bug in next message.
As promised, here it is.

Using that previous batch file, which creates a blank disk with 16 heads per cylinder and 63 sectors per track, I hop into lvmgui and it is happy to create a partition. I choose to do "start of free space" and "primary partition". That creates final1.vhd in the attached. Later on I create a non-bootable compatible volume (final2.vhd) and later on I format it as FAT32 (final3.vhd).

The only change in the MBR between final1 and final3 is the partition type is changed from 06 (FAT16) to 0C (FAT32 using - ironically - LBA). The start/end partition values remain unchanged.

So here is final3.vhd:

C:\vbox>hexdump final3.vhd 0x1b0 80
0001B0  00000000 00000000 00000000 33CC8001  ............3...
0001C0  01000C0F FFB23F00 00009190 0E000000  ......?.........
0001D0  00000000 00000000 00000000 00000000  ................
0001E0  00000000 00000000 00000000 00000000  ................
0001F0  00000000 00000000 00000000 000055AA  ..............U.

Now we can see the x'0c' (FAT32) at 0x1C2 followed by the partition end head number (15 - ie maximum), the FF is sector 63 (x'3f') plus the 2 high bits set for the cylinder number (so B2 becomes 3B2).

So that means that cylinder 3B2 is completely maxed out - as is reasonable - giving cylinder alignment (although note that the starting LBA (after the x'b2') is 3F, so zero based means 40 sectors, ie it starts on head/track 1, sector 1. ie ArcaOS only needs track alignment, not cylinder alignment.

But regardless, the end of the partition is cylinder-aligned, meaning counting from the beginning of the disk (cylinder 0) to the end of the full cylinder 3B2 (946), we have a total of 947 cylinders with various stuff on it (starting with the MBR) or at least, assigned. 947 * 16 * 63 = 954576 sectors "in use". LBA is 0-based counting, so that means 0 to 954575 is "in use". With LBA 954575 being the end sector (inclusive).

That is hex e90cf

But ArcaOS has put an end LBA of e9091

That means if another system tries to use this disk to create the next partition, and uses LBA, as is normal, it will start at x'e9092', potentially trashing data in the first partition.

What is it out by?

cf-91 = decimal 62

So there's the ArcaOS bug - unless I have misdiagnosed.

And that's all the bugs I know of at the moment.

11
Programming / Re: new gcc toolchain
« on: March 16, 2024, 11:23:07 am »
DFSee has this warning,
Warning: The GEO Head/Sectors fields 16/63 in the bootsector         
do NOT match the current disk geometry values 14/63!

Ok, it's been a hell of a ride, with multiple bugs involved.

Let's go through them.

First, (I believe) that DFSee warning is incorrect. They are right about the bootsector values, but wrong about the geometry having 14 heads. It is correctly set to 16 heads.

Running this batch file on Windows:

C:\vbox\final>type doit.bat
del temp.vhd
del temp*.dat
del pdos.vhd
parted mkpart 0x80,0x0c,63,956416 temp.vhd
zcalc 948*63*16+15*63+1
zfill temp1.dat 489717760
xychop temp.vhd temp2.dat 489717760 489718271
copy /b temp1.dat+temp2.dat pdos.vhd
fc /b temp.vhd pdos.vhd

C:\vbox\final>

produces a VHD footer of:

C:\vbox\final>hexdump temp2.dat
000000  636F6E65 63746978 00000002 00010000  conectix........
000010  FFFFFFFF FFFFFFFF 2D8825AC 77696E20  ........-.%.win
000020  00060001 5769326B 00000000 1D308000  ....Wi2k.....0..
000030  00000000 1D308000 03B4103F 00000002  .....0.....?....
000040  FFFFEA8E 73730D77 04246D1E 46011211  ....ss.w.$m.F...
000050  27221837 00000000 00000000 00000000  '".7............

with offset 3A clearly set to x'10', ie number of heads 16.

You can see the number of cylinders (x'3B4' = 948) and the number of sectors after that (x'3F' = 63).


What the message is probably referring to is one of these fields in the partition entry of the MBR:

0001C0  01010C0D 0EB4

The x'0d' is the end of partition head number, ie head number 13, ie the last cylinder has 14 heads being used (0 to 13), with the last head only partially containing data.

That partial data is the x'0e' - 14 - the 14th sector (1 to 14), out of the 63 available sectors.

That (unfortunate) end CHS is due to the parameters given to parted - I haven't given it enough space to complete that last cylinder. So one bug (sort of a bug) is in my batch file - I need to either increase or decrease the space to get an exact cylinder boundary.

There is another bug (already committed - but the bug fix had another bug - and that has been corrected but not committed yet) - the cylinder number is B4. It should actually be 3B4 and the x'3' needs to be put into the top 2 bits of the sector number that is currently x'0E'.

Anyway, DFSee could be incorrectly reporting either of those values that are "14" as "geometry". It's not. It's either number of heads that have full or partial data in the last cylinder of the partition, or it is the number of sectors in the last track/head of the last cylinder of the partition - either thing requires a DFSee bug fix (unless I've misdiagnosed).

Next bug in next message.

12
Programming / Re: new gcc toolchain
« on: March 15, 2024, 11:29:15 pm »
Not much. Help lvm for the command line parameters, addendum.inf (toolkit) has the ioctl programming.
DFsee is available at https://dfsee.com, Jan the author, is pretty knowledgeable, I believe there is a mailing list.
Ok, thanks. But good news - I was looking in the VBR for an issue, as that is what "boot sector" means to me. I have found an issue with the MBR (high 2 bits of cylinder number not being stored in sector number). I'll report back later.

13
Programming / Re: new gcc toolchain
« on: March 15, 2024, 10:55:21 pm »
Thanks. That still doesn't work for me in lvmgui - still says it is free space and still can't create a partition in that alleged free space. But let me try changing the start partition to LBA 14*63*4, which is under 2 MB wastage.
Still no change - but although I zapped the geometry, I didn't change the hidden sectors, so let me first get Robert to decide what he would like to do to resolve the known inconsistency. Will hopefully have an answer overnight. Thanks for all the help.

Robert looked at the VHD that was created by parted and said that the boot sector and VHD were consistent - 16 (x'10') as the number of heads, not 14. So I don't know why dfsee is saying 14 (I'm not saying dfsee is wrong - I just don't know where it is getting that from, as there is no x'0E' anywhere - and no x'0D' either in case it is 0-based counting).

He bought ArcaOS so that he could test it for himself, but after a lot of effort couldn't figure out what was happening, and he is at a loss of what to do without documentation. Is there any documentation for LVM?

Although he doesn't strictly need LVM - he only needs to get as far as the partition being accepted by ArcaOS so that LVM info can be added.

14
Programming / Re: new gcc toolchain
« on: March 15, 2024, 04:56:40 am »
Thanks. That still doesn't work for me in lvmgui - still says it is free space and still can't create a partition in that alleged free space. But let me try changing the start partition to LBA 14*63*4, which is under 2 MB wastage.
Still no change - but although I zapped the geometry, I didn't change the hidden sectors, so let me first get Robert to decide what he would like to do to resolve the known inconsistency. Will hopefully have an answer overnight. Thanks for all the help.

15
Programming / Re: new gcc toolchain
« on: March 15, 2024, 04:41:50 am »
The GEO Head/Sectors fields 16/63 in the bootsector         
do NOT match the current disk geometry values 14/63!
Thanks for that - I'll pass it on to Robert. I tried zapping those values to be correct, but it still didn't change anything.

Quote
I ran "Fix HiddenSectors/Geo value" on the vhd and attaching it.
Thanks. That still doesn't work for me in lvmgui - still says it is free space and still can't create a partition in that alleged free space. But let me try changing the start partition to LBA 14*63*4, which is under 2 MB wastage.

Pages: [1] 2 3 4