Update regs dictionary; Remove LIB.

[arturum1]

- Update uart16550_init function to set the correct initial value for the Line Control Register. The fixed initial value is 0x03. This value should be the same as the reset value from hardware (according to the UART16550 Core Technical Manual). However, if we don't initialize it in software, it seems that the hardware reset value is sometimes not correct. Without this software fix, the uart16550 core would sometimes transmit with 5 bits per character, instead of the correct 8 bits per character. This behaviour was probably due to the wrong init value in the LCR register.

Update:

• Update regs dictionary;
• Remove LIB.

Used for IObundle/iob-soc-opencryptolinux#53

[PedroAntunes178]

Could be accepted. I do not know if it is the correct approach, tho.
In:

iob-uart16550/hardware/src/uart_regs.v

Line 509 in b74ccc1

if (wb_rst_i) lcr <= #1 8'b00000011; // 8n1 setting

it seems as if the register is being correctly reset.
What could be occurring is some problem when the register is read.
Maybe a problem with the iob2wishbone interface in the read. Should be interesting to see if the register is ready to be read immediately when "ack" is signaled.

[PedroAntunes178]

@arturum1 I changed the way rdata is passed on the iob2wishbone wrapper. Could you update the UART16550 and test if the error talked in this commit is persistent?

[PedroAntunes178]

@arturum1 @jjts
Before merging this PR please revert the changes made to software/src/iob-uart16550.c.
Then verify if the issue still presists. I have made an alteration to the wishbone converter that might solve the issue.
Then give feedback.

[jjts]

what changes what issue? I will not revert changes . Can it be accepted and then you change it @PedroAntunes178 ?

[PedroAntunes178]

what changes what issue? I will not revert changes . Can it be accepted and then you change it @PedroAntunes178 ?

This PR was initially formed to solve an issue with the LCR register. I did not have that problem and therefore can not replicate it. I had a similar problem when updating the CPU on OpenCryptoLinux and made a change to the wishbone wrapper that fixed it. That change is already upstream.

In this PR it was presented a software solution to the issue. But it has not been tested with the hardware fix I made. I do not agree with the software fix because it does not read the value with which the register is inicialized.

I can accept the PR and then change the software. However, that would be simillar to reverting the change like I asked @arturum1. And I have no way of knowing if the issue presists for his case. If he made those alteration he could test and check if my fix also works for him.