<rmsyn[m]>
well, thanks for the pointers, I'll keep debugging. Maybe trying machine mode, and switching the linker script to point to the start of SRAM will help
<rmsyn[m]>
tried this before, loaded the binary into FLASH, but didn't use the SRAM offset
<dngrsspookyvisio>
rmsyn: probably Daniel aka CyReVolt 🐢 can help you, he's the resident oreboot expert
<rmsyn[m]>
definitely, he's also the author of the support code for the board I'm working on. If he's in here, I would appreciate hearing from his experience working with the board
<dngrsspookyvisio>
he's not often around but might react to being @-ed
<rmsyn[m]>
true, I've had some interaction via GitHub issues, too. Maybe opening a support issue about build problems would also be a good idea
<DanielakaCyReVol>
here, in the mainboard directory's README
<DanielakaCyReVol>
on that note, I always run oreboot from SRAM for development
<rmsyn[m]>
ok, the loader works, but I had to install `vf2-loader` manually. Also, the UART loader doesn't allow for also connecting with another tty program
<rmsyn[m]>
so, I ended up copying the `starfive-visionfive2-board.fdtbin` file to a SD card, and use u-boot to write it to FLASH
<DanielakaCyReVol>
yea that is currently the easiest way until we have a better tool
<DanielakaCyReVol>
I also mention that in said README, for writing a kernel to flash
<DanielakaCyReVol>
I had put the VF2 stuff aside for the time being, doing UEFI exploitation at the moment because I really needed a break
<rmsyn[m]>
heh, I know the feeling of needing a break
<DanielakaCyReVol>
feel free to @ or DM me anytime here or in Slack :)
<DanielakaCyReVol>
(Matrix being a bit wonky, sorry if I don't reply sometimes... don't always get notified -_-)
<rmsyn[m]>
so, I'm probably going to start working on using the `jh71xx-pac` in `oreboot` to replace the direct register access for the peripherals
<rmsyn[m]>
would a PR for that be welcome? Also working on a `jh71xx-hal`, but that crate is much earlier in development
<DanielakaCyReVol>
Wait what? Where did that PAC come from? Cool stuff!
<DanielakaCyReVol>
Oh you're making it? Yea, I would love to get PRs!
<rmsyn[m]>
awesome :)
<rmsyn[m]>
yeah, it's been a bit of work, and still going through correcting errors from manually translating offsets from the PDF
<rmsyn[m]>
now that I have a running oreboot, testing on the board will be much easier :)
<DanielakaCyReVol>
I also have a branch to improve that setup, on that note...
sajattack[m]1 has joined #rust-embedded
<sajattack[m]1>
Maybe it should be under riscv-rust?
<rmsyn[m]>
@sajattack I'm open to that, but I want to wait until the next patch release at least
<rmsyn[m]>
there have been multiple breaking changes since the last release I pushed
<rmsyn[m]>
:q
<DanielakaCyReVol>
this ain't Vim :D
<rmsyn[m]>
lol, or is it...
<DanielakaCyReVol>
now I look stupid, thanks
<DanielakaCyReVol>
not that that'd be special
<sajattack[m]1>
now I look stupid, thanks
<sajattack[m]1>
Ah sorry fumbled the buttons
<sajattack[m]1>
it's really hard to ping people on fluffychat it turns out. It pulls up a name when you try to at someone and it's impossible to click on it. Anyways I think kvark was asking about bare metal on milk-v mars a month or two ago
<DanielakaCyReVol>
ah yea that's the same SoC
<DanielakaCyReVol>
if Arace were so kind and after 3 months finally sent me the Mars, Mars CM etc I ordered, I could check if oreboot runs fine (and how to select the boot source etc)
<DanielakaCyReVol>
<sajattack[m]1> "risc-v rust-embedded seems a bit..." <- A little note on that:
<DanielakaCyReVol>
When it comes to ISAs used by many chip vendors - such as RISC-V and Arm -, the ISA often plays a minor role. The complexity is really in all the peripheral init etc as you described. And yea, that can get horribly complex. 😅
<sajattack[m]1>
yeah it just seems like arm has more critical mass at the moment
<sajattack[m]1>
in terms of projects around it
<sajattack[m]1>
and chip availability etc.
<DanielakaCyReVol>
<jonathan> "Even the C community is struggli..." <- Well, Milk-V offers 3 platforms at least, including the StarFive JH7110 which is actually nicely documented in many ways already and they are doing great with upstreaming, then some CVITek (e.g. the Milk-V Duo) and Sophon (Milk-V Pioneer).
<sajattack[m]1>
but yeah the gd32vf103 is a testament to your point
<DanielakaCyReVol>
Also the WCH MCUs, CH32xxx, really cool stuff!
<sajattack[m]1>
yeah I just got my wch-link but have zero time to play with it
<DanielakaCyReVol>
and my favourite application SoC the D1 is such a cool thing
<sajattack[m]1>
the reason I mentioned the gd32vf103 is it's a clone of stm32 peripherals with a risc-v isa
<DanielakaCyReVol>
sajattack[m]1: oh some WCHs MCUs can even be flashed without an extra board, which MCUs do you have?
<sajattack[m]1>
v305 iirc
<DanielakaCyReVol>
Ah yea that one needs the WCH Link, I think
<DanielakaCyReVol>
I did a demo "OS" for the CH32V307
<firefrommoonligh>
This is a minor syntax thing, and doesn't affect code architecture, so perhaps it is not worth adding it. But, I think it makes more sense semantically.
Jonathan[m]1 has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh>
Also, ChatGPT is crushing it in writing macros for me, or modifying them so they accept trailing commas etc
<firefrommoonligh>
I think what I don't like about the current syntax is it feels too... magic. As in, the program is extracting which peripheral to use from function name, which is surprising.
<firefrommoonligh>
s/./:/, s/As/The/, s/in, the//
<firefrommoonligh>
* I think what I don't like about the current syntax is it feels too... magic: The program is extracting which peripheral to use from function name, which normally can be arbitrary.
<dngrsspookyvisio>
<firefrommoonligh> "I think what I don't like..." <- Yeah, I've not been a huge fan of the current syntax either. I like your proposal.
<dngrsspookyvisio>
I suppose the current state of things has the benefit of a compiler error on naming collision...
bzdula[m] has joined #rust-embedded
<bzdula[m]>
Hi, does anyone have any idea what this error means: Frame 0: "No active exception." @ 0x08000188 while using probe-rs with this stm32-hal2 quickstart project https://github.com/David-OConnor/stm32-hal-quickstart
<vollbrecht[m]>
dirbaio: if i see it correctly the github releases only include the embedded-hal v1.0.0-rc.3 release and not the once from embedded-hal-async v3 and othere crates ?
<vollbrecht[m]>
* github releases of embedded-hal only include
<vollbrecht[m]>
* dirbaio eldruin : if, * github releases of embedded-hal only include
<vollbrecht[m]>
is that intentional or just an oversight?
Lumpio[m] has quit [Quit: Idle timeout reached: 172800s]
dicklessgreat[m] has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh>
<bzdula[m]> "Hi, does anyone have any idea..." <- I would double check .cargo/config toml, and memory x
<bzdula[m]>
<firefrommoonligh> "I would double check .cargo/..." <- yeah, im working with nucleo-l432kc devkit, so with STM32L432KC mcu, so i changed runner to ``` runner = "probe-rs run --chip STM32L432KCUx " # to list chips, run `probe-rs chip list.``` , rest seems to be okay, thumbv7em-none-eabihf target. Memory.x values seems okay as well...
<bzdula[m]>
> <@firefrommoonlight:matrix.org> I would double check .cargo/config toml, and memory x
<bzdula[m]>
* yeah, im working with nucleo-l432kc devkit, so with STM32L432KC mcu, so i changed runner to `` runner = "probe-rs run --chip STM32L432KCUx " # to list chips, run `probe-rs chip list.`` , rest seems to be okay, thumbv7em-none-eabihf target and whatnot. Memory.x values seems okay as well...
<bzdula[m]>
* yeah, im working with nucleo-l432kc devkit, so with STM32L432KC mcu, so i changed runner to runner = "probe-rs run --chip STM32L432KCUx " # to list chips, run `probe-rs chip list., rest seems to be okay, thumbv7em-none-eabihf target and whatnot. Memory.x values seems okay as well...
AdamHott[m] has joined #rust-embedded
<AdamHott[m]>
Hi All, I'm trying to control the color of a common cathode RGB LED 5 mm on a breadboard connected to a Kitronik Breakout Board, connected to a micro:bit V2. I'm having trouble setting the channels properly and adding a delay. I guess I'm confused on delays in pac vs. hal, and how best to use them. If anyone could tak ea. look I'd greatly appreciate it. Here in my main.rs.
<AdamHott[m]>
But if I try to change to cc.split() or events_compare.split(), then they don't have channel methods to access the channels of the RGB LED
<thejpster[m]>
Can I get a hi-five on https://github.com/rust-embedded-community/embedded-sdmmc-rs/pull/110 from someone please? A PR in which I finally admit there was a bug in embedded-sdmmc and it wasn't just corrupt SD cards - turns out you couldn't create an entry in a root directory that was more than one cluster in length on FAT32.
<AdamHott[m]>
hi-five from me!
<thejpster[m]>
a high-five in this context, is a code review on the linked pull request :)
<thejpster[m]>
I tried to find out where the term comes from, but failed.
<thejpster[m]>
I know we have a "Hi Five" channel at work on Zulip, for tagging people when you have a pull request for them. Maybe it's a Mozilla thing.
m3vict[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
constrain methods usually come from a trait, and trait methods don't work unless the trait is in scope. Does it suggest a trait you should bring into scope that contains a constrain() method and is implemented on the type of PWM0?
<AdamHott[m]>
I think I got it! I didn't initialize pwm correctly!
<AdamHott[m]>
I changed it to let pwm_motor = pwm::Pwm::new(board.PWM0);
<AdamHott[m]>
and now it builds!
<AdamHott[m]>
If this works on the breadboard, then I can write a blog post about it, even though its a very simple example
jr-oss_ has quit [Ping timeout: 246 seconds]
jr-oss has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
Mebus[m]1 has quit [Quit: Idle timeout reached: 172800s]
barnabyw[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
Now you can make directories. This is one of those places where FAT16 vs FAT32 will catch you out - on FAT16 the ".." dir entry has a cluster value of 0 if its parent is the root directory. Otherwise, and on FAT32 it's the cluster containing the parent directory.
<thejpster[m]>
Also, you have to erase the whole cluster containing the new directory, because some FAT code will keep going past entries that start with 0x00. Quite by co-incidence my test code was overwriting an old file that used to contain just 'a' characters, so I had weird directory entries like 'aaaaaaaa.aaa' multiple times.
Guest7282 has left #rust-embedded [Error from remote client]