<oneDragon[m]>
emm, what is the common ways to use jtag?
<oneDragon[m]>
I found a kind of feature names Boundary Scan, but i have no ideas about how to use it (
<oneDragon[m]>
I saw a blog (EEVblog) use XJAnalyser, but seems this application was provide with boards
<oneDragon[m]>
right now seems i could only use openocd or other opensource apps
<K900>
To use JTAG to do what?
<oneDragon[m]>
try to test if MDC(bcmgenet) is working.
<Lumpio->
The Linux driver bcmgenet...?
<oneDragon[m]>
I am porting a NIC driver now, but there is no way to boot the PHY chip correctly
<oneDragon[m]>
> The BCM54213PE enables transmission and reception of packet data only when the descrambler is locked.
<K900>
On your own board design? Or an existing one? Does it even have debug points broken out?
<Lumpio->
oh like your own driver
<oneDragon[m]>
yes, just use raspiberry4B
<Lumpio->
Ok so are you running linux or not
<oneDragon[m]>
but wasn't usual kernel, so i have to convert it to make network run
<Lumpio->
You need to provide a bit of background for anybody to be able to understand what it is that you're trying to debug
<Lumpio->
Is "not usual kernel" a Linux kernel or not
<oneDragon[m]>
* but wasn't usual kernel, so i have to convert it to make network run
<oneDragon[m]>
I don't use linux right now, in fact I wish I could.
<Lumpio->
What kind of kernel is it then
<K900>
And what are you trying to achieve with JTAG here
<oneDragon[m]>
I don't know the classification of this kernel, but it was written by rust and designed based on unikernel design principles.
<K900>
Like, there's no separate JTAG connection for the Ethernet block on the SoC, you get debug access to the CPU cores, but if you're writing your own driver, you already have that?
<K900>
Can you name the kernel?
<K900>
Or is it something you wrote yourself?
<Lumpio->
I don't know if the Soc has that, and if it's documented, but boundary scan could technically get you access to internal signals between the CPU and Ethernet controller, if they're in the same SoC, but whether that's the easiest way of debugging your thing is another question
<oneDragon[m]>
I am copying the register operation in the original driver now, but the feedback above is wrong. link_status is not established successfully.
<oneDragon[m]>
I am now considering checking through JTAG to see if RGMII_MDC provides a signal, since I did not implement this part
<oneDragon[m]>
* I am copying the register operation in the original driver now, but the feedback above is wrong. link_status is not established successfully.
<oneDragon[m]>
I am now considering checking through JTAG to see if RGMII_MDC provides a signal, since I did not implement this part, basically what i done is just convert c register operation into rust.
<K900>
JTAG won't help you with that because that SoC doesn't provide access beyond the CPU with it
<K900>
I believe you can get some more access with some soldering to get to the test points on the GPU
<K900>
But I don't think that will get you to the networking hardware
<K900>
You probably need some proprietary Broadcom arcana for that
<oneDragon[m]>
<K900> "Like, there's no separate JTAG..." <- emm, what's your means of Ethernet block?
<oneDragon[m]>
is it a kind of PHY like bcm54213 or MAC impl in Soc? like mdio connection or others?
<K900>
The Ethernet block is the MAC on the SoC
<K900>
The actual phy does not have any test points at all
<K900>
As far as I can find anyway
<K900>
It's possible there's more proprietary Broadcom arcana
<K900>
But I wouldn't be surprised if it's physically disabled for production units
<Lumpio->
My understanding was "it's all inside the same chip and there's no documented way to look at the internal control signals"
<K900>
The phy is a separate chip
<K900>
But the rest of it, yes
<K900>
And Broadcom is notoriously controlling of their internal documentation
<K900>
So it's not like a Rockchip or Mediatek where you can just find a datasheet on a random FTP server
<K900>
I don't know how true that actually is, but I have second hand information from decently trusted sources that even the RPi Foundation doesn't have full documentation access
<oneDragon[m]>
Well, let me see if there's any way to test this. thk about the help .
<K900>
The way to test this would probably be to just poke the relevant registers yourself from the driver
<oneDragon[m]>
I know, the datasheet of bcm54213 I have now also took a lot of effort to get （
<K900>
Or from a probe attached to the CPU if you really want to go down that route
<K900>
And observe the results
<K900>
But generally you've chosen a really bad platform to write drivers for
<K900>
At least unless you're a Broadcom employee, which you're clearly not
<oneDragon[m]>
To be honest, I'm thinking about something else right now. like ENC28J60 Ethernet module via spi ...
<oneDragon[m]>
* To be honest, I'm thinking about something else right now. like ENC28J60 Ethernet module via spi ...
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
NiaLinaLunaStorm has quit [Quit: Idle timeout reached: 172800s]
RoyBuitenhuis[m] has joined #rust-embedded
<RoyBuitenhuis[m]>
If I would want to have a riscv32ima-unknown-none-elf target to be officially supported by Rust, can I basically commit a copy of a PR that's used to add another riscv32 target? Would this be accepted, or would this just pollute the Rust Targets list? Currently taking Riscv32i, and adding m and a using target flags, but this requires nightly to rebuild the core lib and also seems to be the only reason to keep using nightly
<RoyBuitenhuis[m]>
for now.
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
for it to build the std/core librarys the targets needs to be a tier2 target. And i think some of the riscv targets are now tier2
<vollbrecht[m]>
* for rust lang to build the std/core librarys (and ship it) the targets needs to be a tier2 target. And i think some of the riscv targets are now tier2
<M9names[m]>
yeah, but there's lots of targets that aren't even tier3. and if you accepted every combination of riscv features, that would be a lot of targets
mabez[m] has joined #rust-embedded
<mabez[m]>
<RoyBuitenhuis[m]> "If I would want to have a riscv3..." <- I've done this a few times now, you need to add it as a tier 3 target initially, then open an MCP (Major Change Proposal) to promote to tier 2
<mabez[m]>
M9names[m]: I promoted all the no_std riscv targets to tier 2
<mabez[m]>
actually I tell a lie, only the 32bit ones
<M9names[m]>
okay, but do you really want 90% of all targets to be riscv variants with basically no users?
<M9names[m]>
the espressif ones make sense to me
<M9names[m]>
because they have users
<mabez[m]>
They're all managed by the same platform support doc though, its not much effort to add them but I see what you mean
<mabez[m]>
I'd rather have more targets, even if one of the targets only has one user than block someones use case around maintainability concerns
<mabez[m]>
Another option which might work for Roy Buitenhuis is to use the imac target then pass `-Ctarget-features=-c` to disable the c extension
<M9names[m]>
would that work though? how would it choose which features to have in core?
<mabez[m]>
Well you'd need build-std in this case
<M9names[m]>
without build-std
<mabez[m]>
Yeah no way to do it
<M9names[m]>
if you're already accepting build-std, there's not much point except escaping nightly
<mabez[m]>
Would be good to get other build-std usrers to comment in there, either with issues or that is works fine for their use case
<mabez[m]>
build-std has been working flawlessly for me for nearly 5 years, and is really beneficial for embedded
<M9names[m]>
the only bad interaction i've had with it is that it sometimes interacts badly when providing intrinsics to compiler-builtins, but i'm not sure i'd lay the blame on build-std for that.
<M9names[m]>
i'm squarely on team "std should be less special", though, not sure how the future of build-std is affected by that
<RoyBuitenhuis[m]>
mabez[m]: Thanks, We have been using build-std for a while and never had issues with it.
<RoyBuitenhuis[m]>
* with it. I will comment there.
<RoyBuitenhuis[m]>
A project I'm working on uses Embassy, and since that now compiles on stable, the only reason left for using nightly seems to be the need for compiling the core lib. It's not a must for me to switch to stable, but it would be very nice.
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #rust-embedded
<M9names[m]>
the irony is not lost on me that the issue you linked is about targets that are hard to support, where all the different combinations of riscv features would actually be trivial to support (they're basically the same) but the shear number of different builds of core would bloat out each rustc release by a decent amount.
<mabez[m]>
<M9names[m]> "the only bad interaction i've..." <- > <@9names:matrix.org> the only bad interaction i've had with it is that it sometimes interacts badly when providing intrinsics to compiler-builtins, but i'm not sure i'd lay the blame on build-std for that.
<mabez[m]>
> i'm squarely on team "std should be less special", though, not sure how the future of build-std is affected by that
<mabez[m]>
I think you can get build-std to also build compiler_builtins, `-Zbuild-std=core,compiler_builtins` that might help with those kinds of issues
<RoyBuitenhuis[m]>
<mabez[m]> "Would be good to get other build..." <- I commented about my use-case too now.
<RoyBuitenhuis[m]>
I might submit a PR later when I have time to add the riscv32ima target. Even if it would be a would be nice for me personally, having stable rust supported will also be helpful in convincing my coworkers that embedded Rust is ready to be used on the target.
<RoyBuitenhuis[m]>
* I might submit a PR later when I have time to add the riscv32ima target. Even if it would be a `would be nice` for me personally, having stable rust supported will also be helpful in convincing my coworkers that embedded Rust is ready to be used on the target.
<RoyBuitenhuis[m]>
And if at some point, Cargo has a better way of managing target extensions, that part may be refactored anyway?
<diondokter[m]>
I don't think it has much that is controversial, so reactions would most likely be about giving more info and history perhaps
tangotaylor[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
I might have suggested probe-rs-cli over cargo-embed, and obviously I am contractually obliged to jam defmt into everything (I'm kidding), but that was great.
<diondokter[m]>
Yeah, same. I've never really used cargo embed
<thejpster[m]>
I think even Noah prefers probe-rs-cli these days. Right?
<mabez[m]>
thejpster[m]: It's just probe-rs :) We dropped the -cli postfix a while back. I've only ever used probe-rs directly too, never cargo embed
<thejpster[m]>
yeah but now you have a binary and a library with the same name
<thejpster[m]>
which is one of three binaries (IIRC) shipped in the probe-rs package
<vollbrecht[m]>
i think people learning about probe-rs have all a look at the nice website, and when they read through it [here](https://probe.rs/docs/tools/probe-rs/) come to the conclusion that cargo embeded is the thing to use because it has all this explanation around it while probe-rs has mostly none
<vollbrecht[m]>
s/embeded/embed/
<mabez[m]>
Oh I see what you mean now. I would say probe-rs' cli in the future, just to avoid confusion because probe-rs-cli used to be a thing
<Noah[m]12>
<thejpster[m]> "I think even Noah prefers probe..." <- yup :) but for multi channel RTT you need sth else :)
<thejpster[m]>
the M55 has an optional FPU, an optional integer Helium (MVE) engine, and an optional upgrade to a floating point Helium engine
<thejpster[m]>
I think the bug is you need like six target CPUs. Or the target-cpu to enable the baseline and then a clear set of features you can add on
<thejpster[m]>
it would be nice if +fp64 didn't assume you have space for 32 doubles (D32) when the Cortex-Ms only have D16
<M9names[m]>
<RoyBuitenhuis[m]> "I might submit a PR later when I..." <- > <@roy.buitenhuis-tnl:matrix.org> I might submit a PR later when I have time to add the riscv32ima target. Even if it would be a `would be nice` for me personally, having stable rust supported will also be helpful in convincing my coworkers that embedded Rust is ready to be used on the target.
<M9names[m]>
> And if at some point, Cargo has a better way of managing target extensions, that part may be refactored anyway?
<M9names[m]>
you might as well try. i would be surprised if they didn't let you add it as a tier 3 target at least, which would reduce friction a little bit for you and other rv32ima users.
<thejpster[m]>
target-cpu=cortex-m55 target-features=+fp-armv8,+mve is quite reasonable
RobertJrdens[m] has joined #rust-embedded
<RobertJrdens[m]>
<thejpster[m]> "it would be nice if +fp64 didn't..." <- there's `fp-armv8d16`
<thejpster[m]>
does that enable double precision or single precision instructions?
<thejpster[m]>
and does that work for the FPv5 FPU in the Cortex-M33? (it's not a VFP because the vector stuff got moved out to somewhere else in Armv8-M)
<thejpster[m]>
The M52/55/85 supports f16, the M33 does not AFAIK
Darius has quit [Ping timeout: 246 seconds]
Darius has joined #rust-embedded
NiaLinaLunaStorm has joined #rust-embedded
<NiaLinaLunaStorm>
I'm new to rust and fail to convert a buffer `let mut buf = [0u8, 64];` which is the buffer I read stuff into from a serial interface to an integer. I've found stuff but that's uses std and the stm32f1 examples I've looked at and worked from have no_std
<NiaLinaLunaStorm>
any solution for this?
<K900>
u16::from_{le,be}_bytes?
<diondokter[m]>
NiaLinaLunaStorm: > <@fly:asra.gr> I'm new to rust and fail to convert a buffer `let mut buf = [0u8, 64];` which is the buffer I read stuff into from a serial interface to an integer. I've found stuff but that's uses std and the stm32f1 examples I've looked at and worked from have no_std... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/wXyDkHGIlwNVUuhqQeVXqUlG>)
<diondokter[m]>
And don't worry about that unwrap. It's checked at compile time if the slice is long enough
<NiaLinaLunaStorm>
how does this handle like the case if the buffer should read in more than a single int?
<diondokter[m]>
diondokter[m]: By this I mean that if your code is correct, there's no panic path. If the code is incorrect, then you'll find out at runtime
<NiaLinaLunaStorm>
diondokter[m]: I've got 0 clue about this so I just assume the worst?
<diondokter[m]>
You can get an int from multiple places from the buffer. I updated my example
<K900>
Hold on
<K900>
Is the buffer strings?
<K900>
Or is it actual integers?
<diondokter[m]>
NiaLinaLunaStorm: Nah, I mostly said this so you don't have to worry about the unwrap
<diondokter[m]>
Ah, good question yeah
<NiaLinaLunaStorm>
but how do I know where the int starts?
<NiaLinaLunaStorm>
K900: ascii encoded integers
<diondokter[m]>
That depends on the data that is sent
<diondokter[m]>
NiaLinaLunaStorm: Ah! That makes things different
<K900>
It depends on what your protocol looks like
<K900>
Do you have any separators between your numbers?
<K900>
If not, you should probably add one
<NiaLinaLunaStorm>
K900: new line `0x0A`
<K900>
(but ideally just send them as actual numbers, not text)
<K900>
Do you control the sending side at all or are you stuck with this protocol?
<NiaLinaLunaStorm>
I can change the sending side... but this was more like a quick test via serial. ultimately I wanna make it an USB HID events input device