M-Labs/zynq-rs
11
0
Fork 15
Code Issues 6 Pull Requests Releases Wiki Activity

Kasli-SoC: Get MAC address from EEPROM #90

Merged
sb10q merged 5 commits from mwojcik/zynq-rs:mac_from_eeprom into master 2022-03-07 18:01:44 +08:00
Conversation 7 Commits 5 Files Changed 3 +16 -4
mwojcik commented 2022-03-07 16:59:18 +08:00
Owner
Copy Link

Added pulling data from eeprom using read_eui48 function to libconfig::net_settings. However due to size constraints in SZL, i2c code is just too much and it won't fit in OCM - thus a feature is added that keeps the hardcoded MAC, without pulling the i2c lib in.

Closes #89

Tested with modified experiments (should I include them too in the PR?).

Also get_adress got fixed into get_address (meaning it's a breaking change, artiq-zynq will need to be fixed with the next zynq-rs update).

With MAC taken from EEPROM:

❯ arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.51             ether   e8:eb:1b:45:f9:ad   C                     br0

When compiled with no_i2c feature:

❯ arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.51             ether   02:00:00:00:00:56   C                     br0
Added pulling data from eeprom using ``read_eui48`` function to ``libconfig::net_settings``. However due to size constraints in SZL, i2c code is just too much and it won't fit in OCM - thus a feature is added that keeps the hardcoded MAC, without pulling the i2c lib in. Closes #89 Tested with modified ``experiments`` (should I include them too in the PR?). Also ``get_adress`` got fixed into ``get_address`` (meaning it's a breaking change, artiq-zynq will need to be fixed with the next zynq-rs update). With MAC taken from EEPROM: ``` ❯ arp Address HWtype HWaddress Flags Mask Iface 192.168.1.51 ether e8:eb:1b:45:f9:ad C br0 ``` When compiled with ``no_i2c`` feature: ``` ❯ arp Address HWtype HWaddress Flags Mask Iface 192.168.1.51 ether 02:00:00:00:00:56 C br0 ```
mwojcik added 4 commits 2022-03-07 16:59:19 +08:00
sb10q commented 2022-03-07 17:19:14 +08:00
Owner
Copy Link

However due to size constraints in SZL, i2c code is just too much and it won't fit in OCM - thus a feature is added that keeps the hardcoded MAC, without pulling the i2c lib in.

That doesn't sound very good. We commonly use netboot and changing the MAC address in the middle while keeping the same IP could cause some confusion.
Did you try reducing the stack size or changing compiler options?

> However due to size constraints in SZL, i2c code is just too much and it won't fit in OCM - thus a feature is added that keeps the hardcoded MAC, without pulling the i2c lib in. That doesn't sound very good. We commonly use netboot and changing the MAC address in the middle while keeping the same IP could cause some confusion. Did you try reducing the stack size or changing compiler options?
mwojcik commented 2022-03-07 17:37:51 +08:00
Author
Owner
Copy Link

Stack goes into OCM3, while rodata goes into OCM (so changing stack size won't help).

Changing opt-level to 's' instead of 'z' does let it all fit, even with debug = true. Would that be a better solution?

Stack goes into OCM3, while rodata goes into OCM (so changing stack size won't help). Changing opt-level to 's' instead of 'z' does let it all fit, even with ``debug = true``. Would that be a better solution?
sb10q commented 2022-03-07 17:38:20 +08:00
Owner
Copy Link

Yes.

Yes.
sb10q commented 2022-03-07 17:40:22 +08:00
Owner
Copy Link

And if there are still problems I guess we can put more things in OCM3 by defining a new section and pushing certain data there.

And if there are still problems I guess we can put more things in OCM3 by defining a new section and pushing certain data there.
sb10q commented 2022-03-07 17:41:21 +08:00
Owner
Copy Link

Or if the toolchain has problems with that, remap OCM3 in the assembly startup code so it becomes only one chunk of memory when Rust starts executing. The Zynq technical reference manual explains how to do that.

Or if the toolchain has problems with that, remap OCM3 in the assembly startup code so it becomes only one chunk of memory when Rust starts executing. The Zynq technical reference manual explains how to do that.
mwojcik commented 2022-03-07 17:51:22 +08:00
Author
Owner
Copy Link

It does feel iffy - in theory 'z' opt-level should yield smaller binaries than 's', but in this case it doesn't. No need to change the stack besides that.

It does feel iffy - in theory 'z' opt-level _should_ yield smaller binaries than 's', but in this case it doesn't. No need to change the stack besides that.
mwojcik added 1 commit 2022-03-07 17:51:37 +08:00
mwojcik commented 2022-03-07 17:52:23 +08:00
Author
Owner
Copy Link

Tested with SZL and experiments - same output with arp, pingable.

Tested with SZL and experiments - same output with ``arp``, pingable.
sb10q merged commit 43e0440911 into master 2022-03-07 18:01:44 +08:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/zynq-rs#90
No description provided.
Delete Branch "mwojcik/zynq-rs:mac_from_eeprom"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?