Hi, I would like to get an additional Senoko board, can anyone provide one?
Re: Buster upgrade release (and novena-next announcement) (8 replies, posted in Software)
Wow! Impressive work! Seems like I should be following this forum more closely again. Where can we apply to join the novena-next organisation?
* Senoko seldomly randomly turns on Novena, without any pressure on the power buttons
* Senoko measures completely different voltages than the cells actually have. I tried to graph them and saw very strange curves. (The voltages are definitely correctly at the input pins.) The result of these measurement problems is that Senoko turns the Novena off shortly after power gets unplugged, even though the battery is full and functional.
* The voltage measurements are very far off. Firmware-flashing sometimes helps for a day, on the next day the problem can come again.
* If I remember correctly, the i2c bus-mastering from the battery controller caused issues on the configuration flash of the DRAM modules.
From my point of view, there are too many different chips on the i2c bus, and I am not sure, whether all of them are multi-master capable, so I would really prefer to have this potential problem ruled out.
Then the question is whether the Senoko actually does block the communication or not. And what happens when it unblocks the communication? Can it cause the Senoko to receive only half of a command, resulting in a different interpretation of the command?
I have seen far too much errorneous behaviour of Senokos that I want to rule out every possible potential issue that can be easily designed away.
From my point of view, there is a need to seperate the I2C bus into 2 busses.
Yes, the STM32 should initialize the gas gauge, and it should be the only one talking to the gas gauge. From my point of view, it is a bad idea that both Novena CPU and the STM32 talk to the gas gauge, since those communications can collide.
No, the STM32 does not cease to exist on the bus, it can still control the gas gauge.
I would suggest that we disconnect the I2C bus into 2 busses, one on the Novena and one on the Senoko, and that we route any needed communication over the UART bus instead.
While we are at it, could you perhaps also cleanup the communication mess on the i2c bus? As far as I remember, there is a shared i2c bus between the Novena and the Senoko, and additionally a UART interface between the Novena CPU and the Senoko controller. I would prefer to have the i2c bus split into 2 busses, so that the Novena-Senoko communication only uses the UART. I think this would also increase correctness of the communication and reduce problems.
I have been thinking about organizing a crowdfunding campaign for a new batch of Senoko boards, but all the experiments I did drove me to the conclusion that there is something wrong with the current design of the Senoko boards, and I currently believe that the fault is to be found inside the gas gauge chip. Therefore I would prefer to have the Senokos redesigned with a better chip. Does anyone feel able to do the redesign and provide me with an offer for that? I am willing to get the production organized.
Lately I am seldomly getting Kernel oopses on my Novena, today I had 2 crashes:
Linux version 4.4.0-00156-gc9ba6e8 (xobs@xobs-novena-heirloom) (gcc version 4.9.2 (Debian 4.9.2-10) ) #12 SMP PREEMPT Fri Feb 19 14:32:59 SGT 2016
Does anyone have an idea what the reason or solution could be?
One example log:
Message from syslogd@localhost at May 3 16:09:43 ...
kernel:[ 3805.856500] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
Message from syslogd@localhost at May 3 16:09:43 ...
kernel:[ 3805.962083] Process kworker/0:1 (pid: 1608, stack limit = 0xea898218)
kernel:[ 3805.968526] Stack: (0xea899e70 to 0xea89a000)
kernel:[ 3805.972887] 9e60: ecee68e0 ecee6914 ed3cd440 ed3cc59c
kernel:[ 3805.981069] 9e80: ea899e9c ea899e90 c04b09d8 c01c2a14 ea899eb4 ea899ea0 c04a9404 c04b09c4
kernel:[ 3805.989251] 9ea0: ecee6800 ed3cd740 ea899ee4 ea899eb8 c04c33e4 c04a93b8 c04c3330 ed3ce59c
kernel:[ 3805.997433] 9ec0: eab56780 eddd8bd4 eddd8bc0 edddc400 00000000 00000000 ea899f24 ea899ee8
kernel:[ 3806.005615] 9ee0: c00466fc c04c333c eddd8bc0 eddd8bd4 ea898000 00000008 eab56780 eddd8bc0
kernel:[ 3806.013797] 9f00: eab56798 eddd8bd4 ea898000 00000008 eab56780 eddd8bc0 ea899f5c ea899f28
kernel:[ 3806.021979] 9f20: c0046a68 c00465cc eddd8d54 c0c11100 00000000 00000000 e854cd80 eab56780
kernel:[ 3806.030162] 9f40: c0046a14 00000000 00000000 00000000 ea899fac ea899f60 c004c6ec c0046a20
kernel:[ 3806.038343] 9f60: ea898000 00000000 ea899f94 eab56780 00000000 00000000 ea899f78 ea899f78
kernel:[ 3806.046526] 9f80: 00000000 00000000 ea899f88 ea899f88 e854cd80 c004c600 00000000 00000000
kernel:[ 3806.054708] 9fa0: 00000000 ea899fb0 c0010138 c004c60c 00000000 00000000 00000000 00000000
kernel:[ 3806.062890] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
kernel:[ 3806.071072] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ff2a666f ff2a666f
kernel:[ 3806.134773] Code: e52de004 e8bd4000 e5903248 e1a06000 (e5933024)
kernel:[ 3806.293983] Kernel panic - not syncing: Fatal exception in interrupt
I am sorry, there was a strange problem with the upload, I uploaded it again yesterday, please try again.
I have finally found several previously undocumented GPIOs in the Novena:
http://www2.futureware.at/~philipp/ssd/ … Manual.pdf
Re: how many layers does the Novena Motherboard have? (2 replies, posted in Hardware)
8 layers as far as I remember. You can use my converter https://github.com/thesourcerer8/altium2kicad to convert the Novena PCB design files to KiCad and take a deeper look at them.
What is the supply voltage? My mainboards had problems above 18V, and Novena power supply supplied slightly more (something around 19V). WIth the Senoko in between, the supply voltage was slightly lower and that voltage was fine the Novena mainboard. I am currently using old IBM laptop power supply which are delivering around 16-17 V, which is much better for Novena.
When the mainboard got too much voltage, it usually blinked shortly with a LED, and then it went dark again. In one out of perhaps thirty cases, it succeeded to boot with the high voltage.
I am not interested in an eDP board anymore at the moment.
I added information to the paper about the encryption control: http://www2.futureware.at/~philipp/ssd/ … Manual.pdf
The Ethernet ports are wired to the CPU, as far as I know, so the answer is unfortunately no. I guess one could design and produce an Ethernet Shield for the FPGA.
I am interested in the eDP Display adapter board, and in the bezel with the holes for the connectors (HDMI, USB, Ethernet, power, ...)
You can boot fernly on it, and then use the spi functionality of fernly to backup the firmware
I have some good news, I found a cheap JTAG adapter that works with the Samsung SSDs: Altera USB Blaster. It is about 3-6 times slower than a Novena, but for bigger amounts of data you want to use SATA anyway.
In the mean time, AES and a RNG have been found.
Yes, I am thinking about doing a production run for a few eDP Adapter boards. Anyone interested?
I think I am starting a production run for up to 10 boards. Is anyone interested in boards?
I accidently produced Revision 1 PCBs instead of Revision 2, I'll try to fix them.
Does anyone have a spare eDP adapter board? Mine seems to be broken. :-(
[ 3.291179] it6251 2-005c: error -11 writing to edp addr 0x5
[ 3.291190] dummy 2-005e: it6251.c:it6251_init:285 error -1 writing 255 to 5
[ 3.300295] dummy 2-005e: error -11 writing to lvds addr 0x5
[ 3.300303] dummy 2-005e: it6251.c:it6251_init:295 error -1 writing 255 to 5
[ 3.588324] it6251 2-005c: System status: 0x3c
[ 3.589733] it6251 2-005c: RPCLKCnt: 764
[ 3.591157] it6251 2-005c: Clock: 0x198
[ 3.591868] it6251 2-005c: Ref Link State: 0x00
[ 3.592578] it6251 2-005c: RPC Req: 0x24
[ 3.593986] it6251 2-005c: hactive: 1920
[ 3.595391] it6251 2-005c: vactive: 1080
[ 3.609619] Console: switching to colour frame buffer device 240x67
[ 14.398941] it6251 2-005c: error -11 writing to edp addr 0x5
[ 14.398958] dummy 2-005e: it6251.c:it6251_init:285 error -1 writing 255 to 5
[ 14.407946] dummy 2-005e: error -11 writing to lvds addr 0x5
[ 14.407958] dummy 2-005e: it6251.c:it6251_init:295 error -1 writing 255 to 5
[ 14.695133] it6251 2-005c: System status: 0x3c
[ 14.696530] it6251 2-005c: RPCLKCnt: 764
[ 14.697920] it6251 2-005c: Clock: 0x197
[ 14.698613] it6251 2-005c: Ref Link State: 0x00
[ 14.699312] it6251 2-005c: RPC Req: 0x24
[ 14.700765] it6251 2-005c: hactive: 1920
[ 14.702162] it6251 2-005c: vactive: 1080
I think the old NeTV does not have enough RAM to buffer any delaying. The more delay you want to add, the more RAM you need. Also I think you cannot decode and extract information from the incoming signal with NeTV, you can only overlay it. Perhaps https://hdmi2usb.tv/hardware/ is more suitable for what you need.
Most of the PHYs are figured out mostly now. The sectors can be read out directly from flash now.
I updated the manual: http://www2.futureware.at/~philipp/ssd/ … Manual.pdf
The SSD looks good to me, from a physical point of view, so I don't think that you need SSDdiag. (SSDdiag would be necessary if you would not even see the SSD at all, no serial number, ...)
Regarding the sysfsgpio, please take a look here:
https://www.kosagi.com/w/index.php?titl … AG_adapter
Yes, there is a newer firmware available, which might improve things a bit. If you really want to try to update it, you need a Windows Machine and the software from Samsung. But I wouldn't try a firmware update at this point, it could make things worse as well.
The CRC errors ... I am not sure, whether those are SATA-CRC errors (in this case make sure that the SSD is properly attached to the Novena mainboard, or check your SATA cable in case you are using on), or whether those are Flash CRC Errors.
I think I spotted a relevant error message: sda: unknown partition table. It seems that there is no partition table on it, perhaps it was overwritten?