Econet to AUN bridge on Raspberry Pi - released

discuss both original and modern hardware for the bbc micro/electron
cr12925
Posts: 164
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

arg wrote:
Sun Sep 19, 2021 10:49 pm
Something fishy going on with nRST. It's pulsing low for only a very short time (below the resolution of the analyser to measure it properly, but about 100ns. I've found the datasheet limit now, and that's minimum 400ns. However this is extra odd in that software seems to be pressing on without doing any re-initialisation, and the hardware doesn't seem to mind much either, continuing to generate interrupts! So possibly this is a capture error and it's not actually being genuinely pulsed? However, we should look a little closer at this - the trace I looked at yesterday of the initial start-up seemed to have an illegal pulse width - suggest we need a decent delay when deliberately pulsing nRST.
There's only two places when the code will pulse nRST - so I agree this is v. fishy. The first is in the adapter probe, when it holds it active low for 100ms (not us). The second is in econet_adlc_cleardown(), which is used when the module things something has gone pretty catastrophically wrong and wants to do a wholesale reset. Again, it holds it low for 100ms. So, I don't reckon the software is deliberately generating these short pulses. Each would be accompanied by a messages in dmesg - either on module load, or when it decides to throw its toys out of the pram and start again.
arg wrote:
Sun Sep 19, 2021 10:49 pm
Things like removing the extra read of SR2 will give more margin, and a switch to 2-byte mode would give lots more margin, so not a big concern for supporting the PiZero long term, and in fact I haven't yet found a case in this log where it actually went wrong.
I'm pretty sure the version @KenLowe is testing for these results already removed an extra read of SR2, because I went through and tinkered with that. Since I can't at present read the traces (software issues, not Ken's fault!), if they show two reads then I must have missed one!
arg wrote:
Sun Sep 19, 2021 10:49 pm
[*]However, this does highlight that the unnecessary writes of 0x65 to CR2 (clearing the Rx status) need to go: in some cases here, that write to CR2 occurs after nIRQ has already gone off signalling the next byte available - and if there was (for example) FV status in SR2 to go with that byte, the CR2 write will have silently cleared it.
I thought I'd got rid of the extra writes to CR2 as well - but will look for more... Whilst I've not quoted the observation before about a write to CR1 after receiving bytes, I thought I had ditched that too - I will look again when I get home.
arg wrote:
Sun Sep 19, 2021 10:49 pm
...
And again 123400 to 142280. Around 140815 the level-triggered interrupt is doing its thing - failed to service the previous interrupt before the next one came along, but apparently no overflow. At 142215, things go wrong. SR1=0x81, SR2=0x80 as usual, then there's a pause of 6us when it would normally have done a read of the Rx data but nothing happens, followed by reading SR1/SR2 again (which haven't changed), finally the data is read and CR2 written as usual. The next interrupt then seems slow to service, but maybe the next action (at 142280us) isn't actually an interrupt service at all as it doesn't read SR1 - instead it writes CR2=0x65, CR1=0xe2, CR1=0x82 and all goes quiet for a while, with the end of the frame getting lost.
Now this is the bit I wanted to understand. I think where you see a read of SR1 & SR2, the software actually thinks it's reading the FIFO, hence it's putting those bytes in its data packet storage and producing the dodgy packet that Ken has demonstrated (and I've seen a lot of on my Pi Zero). That is what makes me think something fruity is going on with the address bus, possibly bit 1 thereof - but not all the time. I get very similar behaviour on my Pi Zero - right number of bytes in the packet, but all look like status register content rather than data. It's almost as if A1 is not quite making it to the ADLC sometimes. One possibility is that something odd is being done in the userspace arena with the address lines, but on a different CPU core to the one handling the interrupt. Seems odd that we'd get a whole packet full of status register stuff though.

I will look again at the register writes on reception and see if I can find any more that want removing! Could have sworn I'd done it though, though this morning was littered with a constellation of unusual events which meant I had to work quicker than usual.

C.
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
User avatar
arg
Posts: 438
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

cr12925 wrote:
Mon Sep 20, 2021 1:25 am
There's only two places when the code will pulse nRST - so I agree this is v. fishy. The first is in the adapter probe, when it holds it active low for 100ms (not us). The second is in econet_adlc_cleardown(), which is used when the module things something has gone pretty catastrophically wrong and wants to do a wholesale reset. Again, it holds it low for 100ms. So, I don't reckon the software is deliberately generating these short pulses. Each would be accompanied by a messages in dmesg - either on module load, or when it decides to throw its toys out of the pram and start again.
OK, I think I have an idea about the cause of the glitchy nRST. Note that they always occur just as RnW is being taken from high to low preparatory to a write, and that there's also glitches on the databus at the same time. I think it's ground-bounce caused by high currents to flowing as the bus driver changes direction. Probably only causing these measurement errors, though theoretically it could be causing other general malfunctions.

I was thinking it could be a bus clash caused by software doing things in the wrong order in econet_set_dir() - and indeed that code isn't right, but unfortunately in way that should cause the problem on the opposite edge to where we are seeing it! I'm still suspicious about this function in general though.

The basic issue is that software needs to ensure that the change of GPIO direction setting and the level of the RnW pin itself are done in the right order, such that the databus is never driven by the Pi and the LVC245 at the same time. So when taking RnW high (switching from write to read), the Pi is driving the bus, and the Pi must be switched to inputs before changing RnW to make the 245 drive the bus; going the other way (high to low), the 245 is driving the bus and RnW must be changed first before enabling the Pi pins as outputs (we don't care about the other side with the ADLC on it, as the ADLC only drives that during a nCS cycle and the rest of the time we can drive it or not with impunity).

The code in econet_set_dir() always sets RnW first and then changes the pin direction - this should cause a clash when taking RnW low (as the 245 will start driving the bus while the Pi is still set for outputs), the opposite case to where we are seeing it.

BUT, what do INP_GPIO/OUT_GPIO actually do? I thought they were kernel APIs that you were using, and I had expected them to be very slow (doing it bit-by-bit), however the traces show they aren't taking all that much time and in fact I've now found that they are macros in your include file, accessing the hardware directly just with C pointers without any write barriers! So probably what's happening is that these complete rather quickly without affecting the actual hardware (indeed they are probably subject to compiler reordering - I can't find the definition of GPIO_PORT to see if it's got a cast to volatile in it), hence the GPIO direction updates occur at an unpredictable time and lead to the problem we are seeing.

There's also the oddity of doing a redundant INP_GPIO when what we actually want is OUT_GPIO, with the comment "read somewhere you need to do this". I rather suspect that "somewhere" was comments by somebody else suffering the same sort of problems as we are and found that sticking in something meaningless fluked it into working!

So I suggest:
  • Switch to doing the direction setting with writel() rather than C indirection operators - it's just too hard to get those right, and clumsy once you've smothered it with volatile casts and barrier() calls.
  • Just doing that will make it very slow with the current 8 separate invocations. Suggest you resurrect econet_set_datadir_in() - currently defined but apparently not used - and re-write it to do a single operation for all 8 bits, since it conveniently happens that all 8 are in the same register. You'll still need to do a read-modify-write because there's two other GPIOs in the same register that are not on the 40-pin connector and hence we shouldn't just hard-wire the setting, but it should still be reasonably quick.
  • Ignore this rumour about needing to write the register twice.
  • In econet_set_dir(), if direction is '1' do econet_set_datadir_in() followed by econet_set_rw(1), if direction is '0' do econet_set_rw(0) followed by econet_set_datadir_out()
I'd bet moderate money on that fixing the glitchy nRST issue on the traces; whether or not it has any visible improvement on overall behaviour is more doubtful - but it's good to get it right.
cr12925
Posts: 164
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

arg wrote:
Mon Sep 20, 2021 9:05 am
I was thinking it could be a bus clash caused by software doing things in the wrong order in econet_set_dir() - and indeed that code isn't right, but unfortunately in way that should cause the problem on the opposite edge to where we are seeing it! I'm still suspicious about this function in general though.
econet_set_dir() isn't used in the code Ken is running (see current GH), except for testing purposes. The read/write SR/CR routines change the data bus round themselves and ...
arg wrote:
Mon Sep 20, 2021 9:05 am
The basic issue is that software needs to ensure that the change of GPIO direction setting and the level of the RnW pin itself are done in the right order, such that the databus is never driven by the Pi and the LVC245 at the same time.
The existing code does already swap the Pi inputs to the right direction before changing RnW in normal operation for reading SR/CR. I can see why you think otherwise given econet_set_dir(), but the most recent version doesn't use that in the register read/write functions (which now include the FIFO).
arg wrote:
Mon Sep 20, 2021 9:05 am
The code in econet_set_dir() always sets RnW first and then changes the pin direction - this should cause a clash when taking RnW low (as the 245 will start driving the bus while the Pi is still set for outputs), the opposite case to where we are seeing it.
As above, no longer operative code except via ioctls for test harness purposes.

I can't share the code from where I am, but given all the GPIO pins are in the same register for controlling what they do (in, out, alt etc.), I have made that efficiency alteration and will circulate when I can get near a board to test it!

Best

C.
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
User avatar
arg
Posts: 438
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

cr12925 wrote:
Mon Sep 20, 2021 9:33 am
The existing code does already swap the Pi inputs to the right direction before changing RnW in normal operation for reading SR/CR. I can see why you think otherwise given econet_set_dir(), but the most recent version doesn't use that in the register read/write functions (which now include the FIFO).
Aha. Sorry, I had hit 'refresh' on my browser window to be sure I was looking at the latest github code, but failed to refresh my memory of which functions called what!

Now looking at econet_read_sr() and econet_write_cr() instead, econet_read_sr() gets it right, and econet_write_cr() gets it wrong - which matches what I see on the traces!

There's still the questionable INP_GPIO() macros, but you've put an explicit barrier() after them so it's probably in fact having the desired effect and cleaning this up will just give a very minor efficiency improvement.

To elaborate on what I'm saying is wrong, both functions are currently setting the GPIO direction first and then setting RnW (now doing RnW as part of setting up the address etc, but that's immaterial). When switching from write to read, you must do the GPIO first - so econet_read_sr() is doing it right. When switching from read to write, you must do RnW first (again, no problem to also set the address/data values at the same time) and only afterwards change the GPIOs to outputs.

So you simply need to reorder what you have there - move:

Code: Select all

// Put that lot on the GPIO
	writel(gpioval, GPIO_PORT+GPSET0);
	writel((~gpioval) & gpiomask, GPIO_PORT + GPCLR0)
above the direction setting - in econet_write_cr() only.

The barrier() after the GPIO writes shouldn't be necessary, but the one after the direction change is - at least while you are still using the INP_GPIO macros as they are now.

If you later convert it all to use writel(), with its built-in barriers the one place you might need an explicit barrier() is when a read closely follows a write and depends on it: between econet_set_cs() and the following test of econet_is_busy().
User avatar
arg
Posts: 438
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

cr12925 wrote:
Mon Sep 20, 2021 1:25 am
arg wrote:
Sun Sep 19, 2021 10:49 pm
Things like removing the extra read of SR2 will give more margin, and a switch to 2-byte mode would give lots more margin, so not a big concern for supporting the PiZero long term, and in fact I haven't yet found a case in this log where it actually went wrong.
I'm pretty sure the version @KenLowe is testing for these results already removed an extra read of SR2, because I went through and tinkered with that. Since I can't at present read the traces (software issues, not Ken's fault!), if they show two reads then I must have missed one!
arg wrote:
Sun Sep 19, 2021 10:49 pm
[*]However, this does highlight that the unnecessary writes of 0x65 to CR2 (clearing the Rx status) need to go: in some cases here, that write to CR2 occurs after nIRQ has already gone off signalling the next byte available - and if there was (for example) FV status in SR2 to go with that byte, the CR2 write will have silently cleared it.
I thought I'd got rid of the extra writes to CR2 as well - but will look for more... Whilst I've not quoted the observation before about a write to CR1 after receiving bytes, I thought I had ditched that too - I will look again when I get home.
With all the flurry of activity yesterday, I think I was decoding traces that Ken had taken quite a few hours earlier, so you and he may well have moved on to a different version before I got round to reporting back.

Anyhow, these traces are the "19-02-LOAD ADFS130 - econet-monitor" set from this posting viewtopic.php?p=335108#p335108 at 2:47PM yesterday.

The receive byte interrupt seems to be fairly consistent (apart from the handful of 'broken' ones discussed separately):
  • Reads SR1, then if the SR2RQ bit is set it reads SR2 twice, otherwise reads SR2 once
  • Reads the data byte
  • Writes CR2=0x65 (only once, but every time regardless of whether there was status to be cleared or not)
As noted earlier, the CR2 write should only be done if there is status to clear (in the receive byte situation, AP or FV), but having read the datasheet more closely it's less harmful than I thought (mainly an efficiency loss rather than the cause of misbehaviour I was expecting) since the clear via CR2 guarantees to only clear status you've already read via SR1/2 - so arbitrarily hitting CR2 could be bad, but in the specific case here immediately after reading a data byte I think it's harmless other than using up a fair bit of time.
arg wrote:
Sun Sep 19, 2021 10:49 pm
...
And again 123400 to 142280. Around 140815 the level-triggered interrupt is doing its thing - failed to service the previous interrupt before the next one came along, but apparently no overflow. At 142215, things go wrong. SR1=0x81, SR2=0x80 as usual, then there's a pause of 6us when it would normally have done a read of the Rx data but nothing happens, followed by reading SR1/SR2 again (which haven't changed), finally the data is read and CR2 written as usual. The next interrupt then seems slow to service, but maybe the next action (at 142280us) isn't actually an interrupt service at all as it doesn't read SR1 - instead it writes CR2=0x65, CR1=0xe2, CR1=0x82 and all goes quiet for a while, with the end of the frame getting lost.
Now this is the bit I wanted to understand. I think where you see a read of SR1 & SR2, the software actually thinks it's reading the FIFO, hence it's putting those bytes in its data packet storage and producing the dodgy packet that Ken has demonstrated (and I've seen a lot of on my Pi Zero). That is what makes me think something fruity is going on with the address bus, possibly bit 1 thereof - but not all the time. I get very similar behaviour on my Pi Zero - right number of bytes in the packet, but all look like status register content rather than data. It's almost as if A1 is not quite making it to the ADLC sometimes.
It doesn't look to me like the problem is with the address bits - the interrupt comes in, there's the usual read of SR1/SR2, then a longish pause (about the same amount of time as an interrupt latency?), then the normal sequence of operations from the beginning (read SR1/SR2/read data/write CR1). During that pause nothing happens on the address (or any other) pins. The address pins never change to address SR3/FIFO, and there's no CS triggered to access the ADLC. If the next access (after the pause) is meant to be the missing data read and the address has just gone wrong, that doesn't explain the fact that its followed by a read of SR2 and then an actual read of the data.

From the hardware perspective, it looks most like the IRQ handler just gives up having read SR1/SR2 and returns, but since it hasn't read the data the IRQ line remains active, so it gets interrupted again and does what it was expected to do the first time.

Now it's possible that software thinks it DID read the data byte - something gone wrong with triggering nCS, such that the ADLC doesn't get read and the read function just picked up the data lying around on the bus (which would still be what was left over from reading SR2) - that would be consistent with what you are seeing, but it would need multiple things to have gone wrong to produce this trace. Since the triggering of nCS and the setting of the address bus are separate operations, and neither of them happen on the trace, it seems unlikely.

One possibility would be reading bad data for the SR1 value, so you think there's no data available to read. That would explain this trace, but I'm not sure it's consistent with what you are seeing in your logs - on the face of it, for this particular event in the trace at 142215, nothing would actually have gone wrong as the first interrupt would be just ignored and then the second one comes along quickly enough to recover.

I'll keep going along the trace to see if any of the later examples are more informative.
dp11
Posts: 1332
Joined: Sun Aug 12, 2012 9:47 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by dp11 »

Just wondering how you cope with the potentially high peak interrupt latency :

Pi3 : https://metebalci.com/blog/latency-of-r ... .9-kernel/
Pi4B : https://metebalci.com/blog/latency-of-r ... 19-kernel/
User avatar
hoglet
Posts: 10593
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by hoglet »

dp11 wrote:
Mon Sep 20, 2021 1:18 pm
Just wondering how you cope with the potentially high peak interrupt latency :

Pi3 : https://metebalci.com/blog/latency-of-r ... .9-kernel/
Pi4B : https://metebalci.com/blog/latency-of-r ... 19-kernel/
Related to this point, I think the 68B54 status register has a receive overrun error flag which I imagine would be set if you got data overrun due to excessive interrupt latency. Do you ever see this flag set? Is the current driver written to log cases when it is?
User avatar
arg
Posts: 438
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

dp11 wrote:
Mon Sep 20, 2021 1:18 pm
Just wondering how you cope with the potentially high peak interrupt latency :
Pi3 : https://metebalci.com/blog/latency-of-r ... .9-kernel/
Pi4B : https://metebalci.com/blog/latency-of-r ... 19-kernel/
It's not quite clear what those plots actually mean; it appears from the accompanying description to be the latency through to a user-mode process rather than interrupt latency per-se - ie. the plots include scheduling delays as well as interrupt latency, which is while a real-time-linux makes the difference (as I understand it, real-time linux only affects scheduling and not the underlying interrupt latency which is primarily a function of the individual device drivers and not something the generic kernel can do anything about).

If those were true interrupt latency plots, and they were meaningfully applicable to the Econet case, then the Econet would suffer occasional packet drops under high load - which, while not ideal, would not be disasterous (note that those plots have a log scale Y axis so incidence of the larger delays is low), and as Hoglet says the errors will be flagged by the hardware as overruns and treated like any other kind of transmission failure, prompting packet retry etc.

Currently we don't seem to be seeing any overruns; the PiZero in the condition being recorded by Ken (which I think involved a terminal over WiFi, so a fairly bad case) was relatively close to max tolerable latency, while traces on a Pi4 seemed to have more in hand.
marcelaj1
Posts: 387
Joined: Wed Apr 29, 2020 5:07 pm
Location: Surrey
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by marcelaj1 »

Is there a font of all knowledge document for the configuration files, or an example of beeb, bridge, BeebEm setup?
At the moment if I fire up the PiBridge with econet-monitor running and type in *I AM MASTER on my master I see data listed on the monitor output and it says its coming from station 3c which is correct as my master is station 60, so I can see data on the econet (wire?) side, I get a missing station 0 error.
When I fire up the econet-bridge software with a "-d" I don't see anything when sending from the master, when I fire up BeebEm I get loads of data going up the screen but the from and to are 0. This seems to indicate that the device is responding to the ethernet side.
I am jumping to a bit of a conclusion at this point assuming that the physicals are OK but I have configuration file issues with both the PiBridge and the BeebEm config files.
Ashley.
User avatar
KenLowe
Posts: 2134
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by KenLowe »

arg wrote:
Mon Sep 20, 2021 12:03 pm
With all the flurry of activity yesterday, I think I was decoding traces that Ken had taken quite a few hours earlier, so you and he may well have moved on to a different version before I got round to reporting back.

Anyhow, these traces are the "19-02-LOAD ADFS130 - econet-monitor" set from this posting viewtopic.php?p=335108#p335108 at 2:47PM yesterday.
Confirming that all the tests I did yesterday are with the latest github dev branch that was committed yesterday morning. As far as I'm aware there's been no update since then.
User avatar
arg
Posts: 438
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

KenLowe wrote:
Mon Sep 20, 2021 5:49 pm
Confirming that all the tests I did yesterday are with the latest github dev branch that was committed yesterday morning. As far as I'm aware there's been no update since then.
And in fact the double-read of SR2 is clearly there in the github source - it's in the macro econet_get_sr() that carefully decides whether or not it needs to read SR2 and fakes a value if not, then goes and reads it again anyhow (with comments explaining the reason, that we've discussed previously). Behaviour in the traces matches what the source says.
cr12925
Posts: 164
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

marcelaj1 wrote:
Mon Sep 20, 2021 4:01 pm
Is there a font of all knowledge document for the configuration files, or an example of beeb, bridge, BeebEm setup?
Not as yet, but I accept a set of examples would be handy!

If you pm me, I will try to help but it may take a couple of days owing to work!

C
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
cr12925
Posts: 164
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

arg wrote:
Mon Sep 20, 2021 7:10 pm
KenLowe wrote:
Mon Sep 20, 2021 5:49 pm
Confirming that all the tests I did yesterday are with the latest github dev branch that was committed yesterday morning. As far as I'm aware there's been no update since then.
And in fact the double-read of SR2 is clearly there in the github source - it's in the macro econet_get_sr() that carefully decides whether or not it needs to read SR2 and fakes a value if not, then goes and reads it again anyhow (with comments explaining the reason, that we've discussed previously). Behaviour in the traces matches what the source says.
I have been quietly tinkering whilst away. Stand by for tidied up version in a few days which removes lots if the hackery & fixes the double reads/writes, bus direction set efficiency, and bus direction change issues… (Edit: and reduced sr2 reads / associated nDCD detection…)

For now, though, I do not understand why there is a missing FIFO read in the logic analysis given the code in econet_irq_read(), nor why - since that’s the only way data bytes get into the packet buffer - we get SR1/2 contents in there instead if the right values are making it to the ADLC on A0/1…!!

C
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
User avatar
arg
Posts: 438
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

cr12925 wrote:
Mon Sep 20, 2021 8:05 pm
For now, though, I do not understand why there is a missing FIFO read in the logic analysis given the code in econet_irq_read(), nor why - since that’s the only way data bytes get into the packet buffer - we get SR1/2 contents in there instead if the right values are making it to the ADLC on A0/1…!!
No, it's quite puzzling.

Can I suggest at least a printk() in this clause of econet_irq() ?

Code: Select all

	if (!(sr1 & ECONET_GPIO_S1_IRQ)) // No IRQ actually present - return
	{}
as it should never happen, and I have a sneaking suspicion that it's exiting there (but as yet no clue as to why).

I'm slightly scared of sr1 and sr2 as global variables, though I can't actually see a path to that causing any trouble.

As an aside, is there a reason you like variables/parameters of type short? That used to be a complete no-no on ARM (due to the lack of instruction set support for 16-bit quantities leading to huge code to give the right behaviour); I think more recent ISAs reduce this penalty, but it still seems an odd size to use. This wanders into an issue of style rather than substance, but personally I prefer to use stdint.h and then uint8_t for things like these registers that are specifically 8-bit, uint32_t for 32-bit registers, and int/unsigned int for arbitrary variables where I want the compiler to pick the size.
cr12925
Posts: 164
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

arg wrote:
Mon Sep 20, 2021 8:30 pm
Can I suggest at least a printk() in this clause of econet_irq() ?

Code: Select all

	if (!(sr1 & ECONET_GPIO_S1_IRQ)) // No IRQ actually present - return
	{}
as it should never happen, and I have a sneaking suspicion that it's exiting there (but as yet no clue as to why).
Good plan. I have put that in the tinkering I am doing.
arg wrote:
Mon Sep 20, 2021 8:30 pm
I'm slightly scared of sr1 and sr2 as global variables, though I can't actually see a path to that causing any trouble.
Despite appearances, I am not usually a fan of globals either. However, like you I can't quite see why it would be an issue. I might move them into the econet_data structure at some stage.
arg wrote:
Mon Sep 20, 2021 8:30 pm
As an aside, is there a reason you like variables/parameters of type short? That used to be a complete no-no on ARM (due to the lack of instruction set support for 16-bit quantities leading to huge code to give the right behaviour); I think more recent ISAs reduce this penalty, but it still seems an odd size to use. This wanders into an issue of style rather than substance, but personally I prefer to use stdint.h and then uint8_t for things like these registers that are specifically 8-bit, uint32_t for 32-bit registers, and int/unsigned int for arbitrary variables where I want the compiler to pick the size.
I'm from a generation where if you don't need more than a certain amount of space, you shouldn't use it. Sometimes I forget to follow my own mantra. But when I know I don't need a full int, I will generally pick a short. I did not know there was an inefficiency on ARM, and it might explain a bug that @sweh found in the userspace code a while back - though it was a "bug" which had no ill effects, but it was something that shouldn't have worked but did.

I didn't grow up with the uint types and have never used them. That said, their utility has just struct me - not least for a portable way of storing an AUN sequence number.... I can also see the utility of (e.g.) uint8_t for the registers here. I will probably gradually change things over to them.

Thanks for the tip!

C.
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
marcelaj1
Posts: 387
Joined: Wed Apr 29, 2020 5:07 pm
Location: Surrey
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by marcelaj1 »

cr12925 wrote:
Mon Sep 20, 2021 8:00 pm
Not as yet, but I accept a set of examples would be handy!

If you pm me, I will try to help but it may take a couple of days owing to work!
I can see your in the thick of it with this latest evolution.
I have been digging around in posts and I have a few pointers so I will have a go at implementing a few things and document any successes or a table of failures.
Is there a diagramming package any one uses, I find pictures can explain things far better than help files, I may throw something together and put it out as an image, but that means its static and only any good the day it was created, but I guess I have to start somewhere.

Ashley.
Ashley.
marcelaj1
Posts: 387
Joined: Wed Apr 29, 2020 5:07 pm
Location: Surrey
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by marcelaj1 »

Spent some time reading stuff, seems like I have been leading myself astray (not difficult at the best of times :? )....
The bridge was working I was asking the wrong questions. Did not realise you had to specify "Station 0", so on the Master I typed *I AM SYST got Station 0 not listening, when I typed *I AM 0.254 SYST I got logged in :D
Tried this with BeebEm running on my Windows box and logged in as well.
Created 3 users and logged in from my master, beeb and P.C. Created sub directories and allocated them to the new users sent a couple of files up and copied them around, so success, well almost.....
I can send a message from my beeb to my master and vice versa but I can't send across the bridge so beeb and master can't send to beebem or vice versa, there is either a config issue or the test programs are not able to, I did try adding 0. to the station number but that just killed it.
When sending from the beeb or master to beebem I get OK and a prompt back when sending from beebem it hangs until timeout.
The test programs I got from the beebmaster site and a shorter one from this post
viewtopic.php?p=302386#p302386
these both work sending from the beeb to the master.

Is there an official PiBridge method of sending a message, I know the comms work as I can logon and send and receive files, am I chasing an issue that does not exist?

Ashley.
Ashley.
User avatar
arg
Posts: 438
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

marcelaj1 wrote:
Tue Sep 21, 2021 4:34 pm
The bridge was working I was asking the wrong questions. Did not realise you had to specify "Station 0", so on the Master I typed *I AM SYST got Station 0 not listening, when I typed *I AM 0.254 SYST I got logged in :D
This is a problem with the config on your Master rather than the Pi end - you need

Code: Select all

*configure FS 0.254
User avatar
BeebMaster
Posts: 4537
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by BeebMaster »

marcelaj1 wrote:
Tue Sep 21, 2021 4:34 pm
Did not realise you had to specify "Station 0", so on the Master I typed *I AM SYST got Station 0 not listening, when I typed *I AM 0.254 SYST I got logged in :D
That sounds like the default file server number has been set to 0 by mistake. What does *STATUS FS or *FS show?

ANFS won't allow you to configure or set the file server number to 0 using * commands as it's an invalid station number, so it could be corrupt CMOS RAM, or it's been set to zero by calling OSWORD &13 directly.
Image
cr12925
Posts: 164
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

marcelaj1 wrote:
Tue Sep 21, 2021 4:34 pm

Is there an official PiBridge method of sending a message, I know the comms work as I can logon and send and receive files, am I chasing an issue that does not exist?

Ashley.
No, but…

The master branch does not deal with the curious 4-way handshake that happens on an immediate &85 (immediates are usually 2-way handshake). Also in AUN mode (which is all the bridge presently supports), beebem cannot handle those weird 4-ways either for the moment.

At present therefore, *view, remote & notify do not work on beebem (you’ll find they fail between two beebems, let alone across the bridge!). Further, the master branch of the bridge doesn’t either.

The dev branch does (but still not to beebem - only between two bridges with real beebs on each end of the chain) - but there are three reasons I would discourage you from trying it:

1. It is in a flaky state at the moment.
2. The immediate &85 code is ok but there are transmission issues.
3. Since BeebEm doesn’t support these calls yet (maybe soon), it won’t help you at the moment.

Glad you got it going :D Shout if any issues arise. @arg is correct - log into 254 (or 0.254), or set your FS cmos ram setting on a master to make it work. Beebs you’ll need to specify after every reset unless you want 0.254, in which case just do

Code: Select all

*I AM <username>
Best

C
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
User avatar
Lion
Posts: 482
Joined: Sat Mar 14, 2009 6:56 pm
Location: Woodside, California
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by Lion »

I know I'm behind on this, but I have what is probably a stupid question.

How do you change the password of SYST? *PASS requires the old password as an argument, but the old password is a null string...
marcelaj1
Posts: 387
Joined: Wed Apr 29, 2020 5:07 pm
Location: Surrey
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by marcelaj1 »

I think I just put in a single password and it figured it out or I put a colon in front of it.

Scratch that it does not work today, thought it did yesterday :oops:
Last edited by marcelaj1 on Wed Sep 22, 2021 10:24 am, edited 1 time in total.
Ashley.
marcelaj1
Posts: 387
Joined: Wed Apr 29, 2020 5:07 pm
Location: Surrey
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by marcelaj1 »

BeebMaster wrote:
Tue Sep 21, 2021 5:46 pm
That sounds like the default file server number has been set to 0 by mistake. What does *STATUS FS or *FS show?
The output is as follows
>*STATUS FS
0.0
>*FS
File server is 0

arg wrote:
Tue Sep 21, 2021 5:45 pm
This is a problem with the config on your Master rather than the Pi end - you need

Code: Select all

*configure FS 0.254
I guess that confirms I need to do a *CONFIGURE

>*CONFIGURE FS 0.254
>*STATUS FS
0.254
>*I AM <username>
Station 0 not present


must be missing something because

>*I AM 0.254 <username>
>


is logging me on.
Ashley.
cr12925
Posts: 164
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

marcelaj1 wrote:
Wed Sep 22, 2021 10:19 am
>*CONFIGURE FS 0.254
>*STATUS FS
0.254
>*I AM <username>
Station 0 not present


must be missing something because

>*I AM 0.254 <username>
>


is logging me on.
I suspect the *configure change won't take effect until BREAK or possibly CTRL-BREAK - it may well not be re-read by ANFS until then. Having done the *Configure, try BREAK, then *I AM (etc), and if that fails, CTRL-BREAK. (Power on / off won't do more than CTRL-BREAK in this circumstance.) My guess would be that you'll need CTRL-BREAK but I can't be sure without trying it, because a single BREAK on a M128 will leave you logged into the FS you were talking to before, and so doesn't change the current FS, whereas I'm pretty confident on a CTRL-BREAK the ANFS will re-read the CMOS and set your current FS to whatever is in there.

You are right that your original problem looked like a CMOS RAM config error - station 0 is never going to be a real station. (It is used as the source station for certain econet bridge exchanges I think, but never as a physical or virtual machine.)

Best

Chris.
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
marcelaj1
Posts: 387
Joined: Wed Apr 29, 2020 5:07 pm
Location: Surrey
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by marcelaj1 »

cr12925 wrote:
Wed Sep 22, 2021 11:00 am
I suspect the *configure change won't take effect until BREAK or possibly CTRL-BREAK
That's fixed it - although not sure which would have done it but having just switched the master on I logged straight with *I AM <usernsme>.

That takes me back to the 80s installing Oracle on SUN boxes having to reboot about half a dozen times as you change various parameters and quotas, and if you missed a reboot the install fell over and you had to start again :( (showing my age again)
Ashley.
User avatar
BeebMaster
Posts: 4537
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by BeebMaster »

Lion wrote:
Wed Sep 22, 2021 6:36 am
I know I'm behind on this, but I have what is probably a stupid question.

How do you change the password of SYST? *PASS requires the old password as an argument, but the old password is a null string...
You have to put quotes to signify the null password:

Code: Select all

*PASS "" NEWPASS
In *I AM and *PASS you can use a colon followed by a carriage return to hide the remainder of the command line. The colon can actually go anywhere so you could do:

Code: Select all

*I AM BO:<CR>
:(hidden OT<CR>)
which will log you on as BOOT.
Image
User avatar
Lion
Posts: 482
Joined: Sat Mar 14, 2009 6:56 pm
Location: Woodside, California
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by Lion »

BeebMaster wrote:
Wed Sep 22, 2021 12:37 pm
You have to put quotes to signify the null password:
Well I'm glad that I'm not completely crazy because I did try this!

But it doesn't work, at least with the current version of econet-bridge from gitub:

Code: Select all

>*I AM 253 SYST
>*PASS "" NEWPASS

Bad command
>_
A side-effect of this problem is that I can't login from an Archimedes, which doesn't seem to allow logging on with null passwords, with both the Archimedes and the server reporting "Wrong password" when I try.
User avatar
BeebMaster
Posts: 4537
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by BeebMaster »

I don't think RISC OS stations are fully supported by the Pi Econet Bridge yet. I haven't had a lot of luck so far. Possibly a slightly separate point, but one of the things that seems to happen when logging on from an Archimedes station with a hidden password is that it seems to add an extra character to the command line. I was finding that a few months back when monitoring Econet traffic.
Image
cr12925
Posts: 164
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

BeebMaster wrote:
Wed Sep 22, 2021 8:29 pm
I don't think RISC OS stations are fully supported by the Pi Econet Bridge yet. I haven't had a lot of luck so far. Possibly a slightly separate point, but one of the things that seems to happen when logging on from an Archimedes station with a hidden password is that it seems to add an extra character to the command line. I was finding that a few months back when monitoring Econet traffic.
Do you mean they don't talk to the PiFS, of the Pi Bridge can't deal with their traffic?

E.g. Can you use an Archimedes on an Econet wire to talk to a BeebEm fileserver, but not the PiFS?

C.
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
cr12925
Posts: 164
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

Lion wrote:
Wed Sep 22, 2021 7:29 pm
BeebMaster wrote:
Wed Sep 22, 2021 12:37 pm
You have to put quotes to signify the null password:
Well I'm glad that I'm not completely crazy because I did try this!

But it doesn't work, at least with the current version of econet-bridge from gitub:

Code: Select all

>*I AM 253 SYST
>*PASS "" NEWPASS

Bad command
>_
A side-effect of this problem is that I can't login from an Archimedes, which doesn't seem to allow logging on with null passwords, with both the Archimedes and the server reporting "Wrong password" when I try.
Passwords are maximum 6 characters on both real Acorn FS and PiFS... try

Code: Select all

*PASS "" TEST
C.
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
Post Reply

Return to “8-bit acorn hardware”