Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RAM load doesn't work for me #198

Open
tcal-x opened this issue Oct 21, 2020 · 7 comments
Open

RAM load doesn't work for me #198

tcal-x opened this issue Oct 21, 2020 · 7 comments
Assignees

Comments

@tcal-x
Copy link
Contributor

tcal-x commented Oct 21, 2020

@swillner am I doing something wrong here?

I can't get RAM load to work. I'm building examples/riscv-blink with make LOAD_RAM_ADDR=0x10001000, and loading it with dfu-util -D riscv-blink.dfu. The first bytes of the .elf look good:

10001000 <_ftext>:
10001000:       23c0006f                j       1000123c <crt_init>
10001004:       17ab0f23                sb      s10,382(s6)
10001008:       1000                    addi    s0,sp,32
1000100a:       1000                    addi    s0,sp,32

When I try to load it, the fomu gets stuck in the write phase (rapid blue blinking) with this message from dfu-util:

Download        [                         ]   0%            0 bytesError during download get_status

or, dfu-util says it finished but the fomu is in the red error blinking mode.

I've tried it with different fomu and different foboot versions (v2.0.2, v2.0.3, and v2.0.3-55-ge928b86).

@swillner
Copy link
Contributor

hmm, I had these kinds of problems when I used an address intersecting with currently used ram. Have you tried other addresses? I can also give it a try again with my setup. You directly start from a clean foboot flashed as bootloader and no other program flashed, right?

@tcal-x
Copy link
Contributor Author

tcal-x commented Oct 28, 2020

Hey, I think that's it. If I do make LOAD_RAM_ADDR=0x10001200, then it works. This is with v2.0.3 foboot.

@mithro
Copy link
Member

mithro commented Oct 28, 2020

Guess we should have more documentation around this?

@tcal-x
Copy link
Contributor Author

tcal-x commented Oct 28, 2020

Yep, we can update the doc to use something that works. Should we try to figure out what changed and causes 0x10001000 to no longer work?

@mithro
Copy link
Member

mithro commented Oct 28, 2020

Probably!

@tcal-x
Copy link
Contributor Author

tcal-x commented Oct 30, 2020

There are some symbols in bios.elf that now use locations above 0x10001000:

$ nm bios.elf | grep 10001
10001200 B _ebss
10001200 B _end
10001128 b out_buffer
100011a8 b previous_setup_packet
100011b4 b rx_buffer
100011f4 b setup_packet

@mithro
Copy link
Member

mithro commented Oct 30, 2020

@tcal-x - I agree with @xobs that we should put something into the foboot build script which checks that the bios doesn't use anything past the address we are giving for ram load.

@tcal-x tcal-x self-assigned this Oct 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants