Pi1MHz Software

[BeebMaster]

Yes, I'll have a go at that with one change at a time. All this talk of pulls, branches, forks, sounds like whoever devised it was a keen gardener!

A couple of things in the meantime...

I was hindered a bit yesterday as the debug kernel doesn't seem to be working. ADFS never mounts and eventually times out with "Drive not ready" and the serial debug goes into a fairly slow loop of "Unable to open LUN file" type messages. Can anybody see if they can get the debug kernel working from the latest master?

Secondly - although this may not matter so much now as I think I have got 22 and 24 byte .dsc files working - when I have a file open, how can I get the length of the file? This bit from filesystem.c will open a LUN's descriptor file:

Code: Select all

   FIL fileObject;
   // Check if the LUN descriptor file (.dsc) is present
   sprintf(fileName, "/BeebSCSI%d/scsi%d.dsc", filesystemState.lunDirectory, lunNumber);

   if (debugFlag_filesystem) debugStringInt16_P(PSTR("File system: filesystemCheckLunImage(): Checking for (.dsc) LUN descriptor "), (uint16_t)lunNumber, 1);
   fsResult = f_open(&fileObject, fileName, FA_READ);

How then do I get the length of the file into a variable? This suggested itself to me on a search, but I couldn't adapt it to work with the existing file opening code:

Code: Select all

FILE *fp = fopen("filename", "rb");
fseek(fp, 0, SEEK_END);
int lengthOfFile = ftell(fp);
fclose(fp);

What happens if I try to read beyond the end of the file - say, try to read 24 bytes from a file 22 bytes long?

[hoglet]

Can anybody see if they can get the debug kernel working from the latest master?

I can try, once the Beeb-Room has dropped a couple of degrees.

Secondly - although this may not matter so much now as I think I have got 22 and 24 byte .dsc files working - when I have a file open, how can I get the length of the file?

The BeebSCSI code uses the FATFS library to access files on the SD Card. The f_stat function will give you the size of a file in bytes:

Code: Select all

FILINFO fno;
FRESULT fr = f_stat(fileName, &fno);
if (fr == FR_OK) {
    printf("size = %lu\n", fno.size);
} else {
    printf("an unexpected error occurred: %d\n, fr);
}

(not actually tested, but something along these lines should work)

Dave

[BeebMaster]

I can try, once the Beeb-Room has dropped a couple of degrees.

I know what you mean, this from a cold start just now!!

[dp11]

Fresh debug build works for me ( Pizero2W )

[BeebMaster]

Maybe I've been doing something wrong...I just compile it and then change config.txt to un-comment out the "debug" line.

[dp11]

Did you build the debug version ?

configure_rpi.sh -DDEBUG=1
make

[hoglet]

Fresh debug build works for me ( Pizero2W )

I think I win on temperature:

Did you test ADFS/BeebSCSI?

I'm seeing the same problem that BeebMaster had.

It's looks like it's this commit that's responsible: 1d9dcfb0

Code: Select all

**** Raspberry Pi 1M�enable_MMU_and_IDCaches
LED pin 47
    FIRMWARE_VERSION : 61967cd1
         BOARD_MODEL : 00000000
      BOARD_REVISION : 009000c1
   BOARD_MAC_ADDRESS : dceb27b85f389036
        BOARD_SERIAL : 30dc369000000000
          ARM_MEMORY : 000000001f000000
           VC_MEMORY : 1f00000001000000
           EMMC_FREQ :    200.000 MHz    200.000 MHz    200.000 MHz
           UART_FREQ :     48.000 MHz   1000.000 MHz   1000.000 MHz
            ARM_FREQ :   1000.000 MHz   1000.000 MHz   1000.000 MHz
           CORE_FREQ :    400.000 MHz    400.000 MHz    400.000 MHz
            V3D_FREQ :    300.000 MHz    300.000 MHz    300.000 MHz
           H264_FREQ :    300.000 MHz    300.000 MHz    300.000 MHz
            ISP_FREQ :    300.000 MHz    300.000 MHz    300.000 MHz
          SDRAM_FREQ :    450.000 MHz    450.000 MHz    450.000 MHz
          PIXEL_FREQ :      0.000 MHz  -1894.967 MHz  -1894.967 MHz
            PWM_FREQ :      0.000 MHz    500.000 MHz    500.000 MHz
           CORE TEMP :  39.01 °C
        CORE VOLTAGE :   1.35 V
     SDRAM_C VOLTAGE :   1.20 V
     SDRAM_P VOLTAGE :   1.20 V
     SDRAM_I VOLTAGE :   1.20 V
            CMD_LINE : bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 dma.dmachans=0x7ff5 bcm2708.boardrev=0x9000c1 bcm2708.serial=0x30dc3690 bcm2708.uart_clock=48000000 bcm2708.disk_led_gpio=47 smsc95xx.macaddr=B8:27:EB:DC:36:90 vc_mem.mem_base=0x1fa00000 vc_mem.mem_size=0x20000000  console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait


**** Raspberry Pi 1MHz Emulator ****

File system: filesystemInitialise(): Initialising file system
SCSI State: Initialising SCSI emulation


SCSI State: Resetting SCSI emulation

File system: filesystemReset(): Resetting file system
File system: filesystemDismount(): Dismounting file system
File system: filesystemDismount(): Successful
File system: filesystemMount(): Mounting file system
File system: filesystemMount(): Successful
M5000 FX ID : 2
Framebuffer address: 1F95B000
Initialised Framebuffer: 640x512 8bpp
Pitch: 640 bytes
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


**** Raspberry Pi 1MHz Emulator ****



SCSI State: Resetting SCSI emulation

File system: filesystemReset(): Resetting file system
File system: filesystemDismount(): Dismounting file system
File system: filesystemDismount(): Successful
File system: filesystemMount(): Mounting file system
File system: filesystemMount(): Successful
M5000 FX ID : 2
Framebuffer address: 1F95B000
Initialised Framebuffer: 640x512 8bpp
Pitch: 640 bytes
SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 0 0 0 2 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 0, Blocks = 2
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): ERROR: Unable to seek to required sector in LUN image file!
SCSI Commands: ERROR: Open LUN image failed!
SCSI State: Status.  Status byte = 2
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out
SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 3
SCSI Commands: Received command operand bytes: 3 0 0 0 0 0
SCSI Commands: REQUESTSENSE command (0x03) received
SCSI Commands: Target LUN = 0
SCSI Commands: Sense bytes = 4
SCSI State: Information transfer phase: Data in
SCSI Commands: Error flagged - sending to host
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out

Too hot to debug at the moment!

Dave

[dp11]

I did test , I'll have another look

[dp11]

Strange. My commit id 380d686 appears to work. I've just pushed a very minor change to arm-start.S which also appears to work for me. I've test PizeroW and Pizero2W. Are you both using the Pi firmware from the firmware directory ?

[hoglet]

Strange. My commit id 380d686 appears to work. I've just pushed a very minor change to arm-start.S which also appears to work for me. I've test PizeroW and Pizero2W. Are you both using the Pi firmware from the firmware directory ?

No, we are both building our own kernels.

I suspect what's happening here is there is a buffer somewhere that needs to be zero'd, and as of this commit no longer is. And the inconsistent results is down to compiler version we are each using.

I'm using ARM GCC 11.2.1

What are you using Dominic?

Dave

[dp11]

in filesystem.c line 67 can you try removing the NOINIT_SECTION ?

Code: Select all

// File system state structure
NOINIT_SECTION static struct filesystemStateStruct
{
   FATFS fsObject;         // FAT FS file system object
   FIL fileObject[MAX_LUNS];         // FAT FS file objects
   DWORD clmt[MAX_LUNS][SZ_TBL];

   bool fsMountState;      // File system mount state (true = mounted, false = dismounted)

   uint8_t lunDirectory;   // Current LUN directory ID
   bool fsLunStatus[MAX_LUNS]; // LUN image availability flags for the currently selected LUN directory (true = started, false = stopped)
   uint8_t fsLunUserCode[MAX_LUNS][5];  // LUN 5-byte User code (used for F-Code interactions - only present for laser disc images)

} filesystemState;

[hoglet]

in filesystem.c line 67 can you try removing the NOINIT_SECTION ?

I was just about to post that this was the issue, and you beat me to it! Yes, that fixes things.

The failure code was 9 (FR_INVALID_OBJECT)

Why is this only an issue in the debug build?

Dave

[dp11]

I have no idea why it effect debug builds. I've push a commit which might fix it.

[BeebMaster]

Did you build the debug version ?

configure_rpi.sh -DDEBUG=1
make

Ah. No. Just used release.sh and then re-instated the debug line in config.txt. Doing the above doesn't seem to work either, so it must be what Hoglet said.

In view of my muddying the waters on an earlier occasion concerning the versions of ARM/GCC/AA/RAC/BBC/ITV I am running, I decline to comment further.

[dp11]

release.sh is fine just builds four kernels. So build is over four times longer. Using configure once and make when you make changes is significantly quicker.

[hoglet]

Dominic,

Your earlier fix (which I missed) also resolves it:
https://github.com/dp111/Pi1MHz/commit/ ... 4e4baada3f

(so that commit works fine, even without the NOINIT_SECTION change)

Dave

[dp11]

Thanks for testing certainly a weird bug .

[BeebMaster]

Yes, that fixes the debug for me as well.

[hoglet]

Yes, that fixes the debug for me as well.

Just to avoid confusion, what extactly does "that" refer to?

[BeebMaster]

Sorry, "that", was this:

Dominic,

Your earlier fix (which I missed) also resolves it:
https://github.com/dp111/Pi1MHz/commit/ ... 4e4baada3f

(so that commit works fine, even without the NOINIT_SECTION change)

Dave

[BeebMaster]

I've made a fork and branch here:

https://github.com/beebmaster/Pi1MHz

I've made 2 changes so far to fix:

1. "Verify forever" problem referred to earlier in this thread
2. Read capacity returning the wrong data.

If I'm doing it right, I'll carry on with the next thing.

[dp11]

I don't see the read capacity fix did you push it?

[BeebMaster]

Ermm...don't know...it looks like this from here:

[BeebMaster]

I have "created pull request" now, is that the same as pushing?

[dp11]

I see the pull request.

Could you possibly do it as two separate requests ( one for each fix).

Ps I'm going to have to be a lot more disciplined with my commits now.

[hoglet]

Could you possibly do it as two separate requests ( one for each fix).

So what's most important here is each fix is a seperate commit, which is the case here. That really helps when bisecting to find a bug. It also makes it easy to revert a change. It should go without saying that no commit should break the build, because that makes bisecting a real pain.

I'm interested in what you see as the benefit of seperate pull requests? Once merged, the end result is the same.

It's well worth learning how to merge manually using the git command-line, rather than by pushing buttons on github. Then you don't even need a pull request to be able to incorporate commits from a remote repository. And you can merge/test them one at a time if that's what you want to do.

I wonder if git best practice would be a good topic for discussion at tonight's ABUG Dev Night? I'm far from an expert (and especially hate merge conflicts) but I've been actively using it for 14 years now, so I know it pretty well. Even if you are the only person working on a private projest, there are very good reasons for using source code control like git.

Dave

[BeebMaster]

I think I did it wrong at first, I made a fork, then some changes to that (the "verify forever" fix), and then made a new branch from there for the read capacity fix, then sent a pull request for that.

So probably I should have made a branch straight after my own fork before doing anything else, and have a new branch for each individual fix.

I can start again if that will sort it out.

So far these changes are independent of each other but I am not sure what will happen if I make more changes which are dependent on earlier changes.

[BigEd]

As an observation, if you edit a file on github, in the web interface, it'll make a new branch on your fork just for that change, and once it's merged, prompts you to delete it. So, a branch (a feature branch, we might say) can be a short-lived thing, to be used for a single purpose and to be the source of a pull request, and to be deleted after it's been merged upstream.

It might well be, though, that Dave can explain his workflow which might be better than mine!

Dave, I wonder if you could start a thread on git practices? I have various links, and ideas, but here's probably not the place.

[Mince]

I think I did it wrong at first, I made a fork, then some changes to that (the "verify forever" fix), and then made a new branch from there for the read capacity fix, then sent a pull request for that.

So probably I should have made a branch straight after my own fork before doing anything else, and have a new branch for each individual fix.

I can start again if that will sort it out.

So far these changes are independent of each other but I am not sure what will happen if I make more changes which are dependent on earlier changes.

If the change is to different files, you can go back and check out the original main/master/dev/whatever branch and then checkout individual files from your mistaken branch (e.g. "git checkout main; git checkout -b verifyfix; git checkout main -- src/editedfile.c") and then commit and push, so you don't have to necessarily throw everything away. (Of course, you could just copy the file somewhere else, or paste bits in, if you want to do it separately.)

If the changes are dependent on one another, I think it would probably be worth making separate branches for each but with the second change downstream of the first change's branch. You can then make pull requests for each branch separately. If they're to different files, then it's not an issue; if they're to different parts of the same file but can be made independently, git is pretty good about working out how to combine them.

The important thing is what sweh said: git branches are not heavyweight entire copies of the repository but just a pointer to a particular commit that can move along and references all the same files. This makes creating, rebasing, merging, destroying them all very easy and disposable. Don't be afraid of making lots of them.

I'm personally a big fan of rebasing: at work, for the past few months I've been working on a new network configuration for our border in a branch. When my colleagues make changes to the live network master branch I can just rebase my branch on top of theirs and pick up all the other changes and fix up any clashes offline. When we went live with the new border configuration I just merged the 'border' branch into 'master' to make it live (and, of course, the three of us hefting the new routers into the racks which, unfortunately, git can't do itself).

[!FOZ!]

Random thought... has there been any interest in emulating BeebSID? It is already supported in one of the Beeb emulators.