{"action":"closed","issue":{"url":"https://api.github.com/repos/machinekit/mksocfpga/issues/52","repository_url":"https://api.github.com/repos/machinekit/mksocfpga","labels_url":"https://api.github.com/repos/machinekit/mksocfpga/issues/52/labels{/name}","comments_url":"https://api.github.com/repos/machinekit/mksocfpga/issues/52/comments","events_url":"https://api.github.com/repos/machinekit/mksocfpga/issues/52/events","html_url":"https://github.com/machinekit/mksocfpga/issues/52","id":165970894,"number":52,"title":"handling of Firmware ID protobuf message unclear","user":{"login":"mhaberler","id":901479,"avatar_url":"https://avatars.githubusercontent.com/u/901479?v=3","gravatar_id":"","url":"https://api.github.com/users/mhaberler","html_url":"https://github.com/mhaberler","followers_url":"https://api.github.com/users/mhaberler/followers","following_url":"https://api.github.com/users/mhaberler/following{/other_user}","gists_url":"https://api.github.com/users/mhaberler/gists{/gist_id}","starred_url":"https://api.github.com/users/mhaberler/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mhaberler/subscriptions","organizations_url":"https://api.github.com/users/mhaberler/orgs","repos_url":"https://api.github.com/users/mhaberler/repos","events_url":"https://api.github.com/users/mhaberler/events{/privacy}","received_events_url":"https://api.github.com/users/mhaberler/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":26,"created_at":"2016-07-17T10:35:56Z","updated_at":"2016-11-01T16:23:33Z","closed_at":"2016-11-01T16:23:33Z","body":"continuation of discussion in https://github.com/machinekit/mksocfpga/pull/51 (PR is the wrong place); intended to hash out the logic how this descriptor is handled.\n\nwhere we are:\n- we can encode a protobuf message in the FPGA firmware, accessible through a Gtag ID (F8) or at a well-known address (0xF800)\n- the first word at 0xF800 is the length field (u32). If zero, no fwid message is present. @cdsteinkuehler _is this a safe assumption to make?_\n- we can read and decode this message in hostmot2.c\n- if the length field is unreasonable, or the protobuf decoding fails, a message should be logged\n- the values in this message are intended to default the hard-coded values in hm2_llio as [set here](https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/mesa-hostmot2/hm2_soc_ol.c#L401-L406):\n\n```\n    brd->llio.num_ioport_connectors = 2;\n    brd->llio.pins_per_connector = 17;\n    brd->llio.ioport_connector_name[0] = \"P3\";\n    brd->llio.ioport_connector_name[1] = \"P2\";\n    brd->llio.fpga_part_number = 0; // \"6slx9tqg144\";\n    brd->llio.num_leds = 2;\n```\n\nrequirements:\n- any existing drivers must continue to work unchanged.\n- there will be firmware blobs which have that fwid message, and some may not (or not yet). Handle both cases gracefully\n- especially during development it makes sense to override any fwid message in the FPGA image (or pretend it was there). This can be done by passing a 'fake' encoded message+length up from llio.\n\nmy current idea of a flow hence is:\n- if the message length field is unreasonable, or the protobuf decoding fails, a message should be logged and llio values left unchanged but operation continues (in case there are random values in the msg length location)\n- if a fwid proto message is present (either in the FPGA image, or passed 'up' via the llio driver), override `brd->llio` values `num_ioport_connectors pins_per_connector ioport_connector_name.. fpga_part_number  num_leds`\n- applying the fwid proto message can be skipped by the \"nofwid\" keyword in the config string, in which case the values passed up from the llio driver remain untouched; this keyword sets the new field `hostmot2_t.config.skip_fwid`\n- else leave values in `brd->llio` alone\n- a llio driver supporting a 'fake' fwid message will take that from a file, as directed by the \"descriptor=<fwidmsg.bin>\" flag - this file contains the override message\n- llio \"passes up\" this fwid message in the new struct hm2_lowlevel_io_struct fields `fwid_msg` and `fwid_len`\n- hm2_register() inspects the `fwid_msg` and `fwid_len` fields and - if non-zero - takes this message instead of the one from the FPGA image.\n"}}
{"actor":{"display_login":"cdsteinkuehler"}}