Freshly built doesn't boot #43
Description
Activity
Congrats on building one! If you set the baud rate for your serial to 38400 (I think) do you see anything? The boot rom in the chip if it is working will print out some debug stuff.
I haven't touched this stuff in ages but I'll help you to get it going.
First of all, thank you very much!
I tried but got nothing. At the moment I suspect that the crystal is not working because I tried 2 MSC313Es but they all had this problem.
I'll attach two pictures of how I did it, but first I had no way to write the SPi chip itself on the crib board so I improvised with a gold connector, glue and some cable.
If you stick a multimeter in voltage mode on the crystal do you see anything?
I can't see anything, so I suspect that's where the problem might be. But this is my last guess.
I can't see anything, so I suspect that's where the problem might be. But this is my last guess.
Ok, you should check you are getting the correct voltages on the different rails.
I have checked and there is the right voltage everywhere.
I ordered a new crystal, as soon as it arrives I will replace it and report back. Should be here in 2-3 working days.
Sorry for the delay, I got the crystal, I managed to put it on and now I have about 1.5V there but it still won't start and I get nothing on UART. I checked all the voltages again and everything is there, the machine recognises the CH340 as before but spits out nothing.
@fifteenhex I was wondering if there's any way I could measure if the chip is working?
@fifteenhex I was wondering if there's any way I could measure if the chip is working?
Give me a day or so to get back to you. Work is crazy at the moment.
Feel free and thank you for spending your free time on my problem.
I think if you are seeing ~1.5v the oscillator is running. Try connecting minicom at 38400 baud and while it is connected to usb manually reset the chip by connecting a wire to the point between c37 and r23 (the reset circuit) and poking it on a 3.3v connection. You should see characters come out and that'll tell you what is wrong.
Also if you want to drop me a private email I can probably send you a working board so you can compare against yours.
Unfortunately I have a windows computer so I tried what you described with a program called realterm. But it did not detect anything even though I tried many times.
I was thinking that the chip itself might be bad and then I made a breakout board (which hasn't arrived yet) and put together the basics based on your schematic, i.e. the SPI chip, the power sources and the decoupling capacitors. Maybe it will produce something.I will gladly accept your offer if you really have a working piece. I've even thought that if you have the time and the capacity, I'll send you my board and see if you have more advanced tools to debug it.
My private email address is *
- Nowadays doing with electronics is paradise: basic tools are dirt cheap, boards also, it´s easy to program, there are zillions of resources online. I can only recommend buying few basic tools when working with digital electronics: a dirt cheap logic analyzer can be had for less than 10$, even as cheap a FIVE bucks. Ebay or aliexpress with "logic analyzer 24MHz 8 channels" and you´ll find a little jewel that does not break the bank. Use some opensource software with it like pusleview (win/mac/linux) and go on youtube for some hands-on learning. You´ll learn a lot, you´ll spot problems, it´s worth every cent and minute of your time. Sure it´s limited to 24MHz, but just define a slower clock when you initialize your SPI bus, and it´s ok! (My first logic analyzer weighted easily 30kg, took half of my desk, and costed me a whole two months of summer job money - second hand) Am So., 20. Okt. 2024 um 19:20 Uhr schrieb stonehencs < ***@***.***>:…Unfortunately I have a windows computer so I tried what you described with a program called realterm. But it did not detect anything even though I tried many times. I was thinking that the chip itself might be bad and then I made a breakout board (which hasn't arrived yet) and put together the basics based on your schematic, i.e. the SPI chip, the power sources and the decoupling capacitors. Maybe it will produce something. I will gladly accept your offer if you really have a working piece. I've even thought that if you have the time and the capacity, I'll send you my board and see if you have more advanced tools to debug it. My private email address is ***@***.***| so if you saw the post I'll delete it from here. image.png (view on web) <https://github.com/user-attachments/assets/233cdecb-5a6b-4c60-983a-5d64b6db7184> image.png (view on web) <https://github.com/user-attachments/assets/f928dfed-474a-4428-af05-536de8468f48> — Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4PHYIDJI4SDESHDYXKLX3Z4PQ5LAVCNFSM6AAAAABPBTZB2SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRVGEZTMMBVGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
@pak-man
You're absolutely right, I was thinking mainly of an oscilloscope, but you're right that I can use a cheap logic analyzer to see if there's any movement on the SPI channel and UART.
Thanks for the idea!@stonehencs one of the cheap analyzers that work with sigrok would be enough to check if its doing anything. But the oscillator running is a sign that the chip is doing something.
I send you a mail in a few days about sending a finished. On a trip at the moment.27 remaining items
@fifteenhex I tried, especially now that I know that's the official gpio address. But I can't get it to work, it always throws an error on nmap call or memory errors. Maybe you could send me some example code or a web page with this documented?
Link my code: https://github.com/stonehencs/costum_package/blob/main/br2apps/package/bence/raw/gpio_teszt.cMy other question is that I tried to add a read/write partition and found that it already automatically creates one and mounts it in rw directory. However, if I create one and then try to copy it to the rw partition in genimage.cfg, it will find the files I put in it, but it throws this error:
jffs2: error: (72) jffs2_build_inode_fragtree: Add node to tree failed -22 jffs2: error: (72) jffs2_do_read_inode_internal: Failed to build final fragtree for inode #2: error -22
I'm not sure about the rw partition issue but I think the GPIO one is one of the options in the kernel config like CONFIG_STRICT_DEVMEM.
So I just enable it and I should have proper access to the memory?
However, do you remember where you created the rw partition? Or just by fstab and from the dts partition? I mean, is it created by the system at boot time and not during a build?
The r/w partition should be in the dts under the nor flash node and I think there is a script that is run on boot in /etc/init.d/ that tries to mount it (and maybe run the jffs2 format thing if needed?).
I couldn't find anything there except a script to create the /rw/dropbear directory. I found that it is also set to automount in fstab.
Hi @fifteenhex !
Sorry to bother you again, but I took out my Breadbee to work on a project and once again I can't get it to boot, which has me a bit confused:
If I download Buildroot from the link provided here, I get this error when running bootstrap:
git submodule init Submodule 'br2autosshkey' (https://github.com/fifteenhex/br2autosshkey.git) registered for path 'br2autosshkey' Submodule 'br2sanetime' (https://github.com/fifteenhex/br2sanetime.git) registered for path 'br2sanetime' Submodule 'buildroot' (https://github.com/fifteenhex/buildroot.git) registered for path 'buildroot' Submodule 'buildroot_rescue' (https://github.com/fifteenhex/buildroot.git) registered for path 'buildroot_rescue' git submodule update Cloning into '/home/alma/Desktop/breadbee/a/breadbee_buildroot/br2autosshkey'... Cloning into '/home/alma/Desktop/breadbee/a/breadbee_buildroot/br2sanetime'... Cloning into '/home/alma/Desktop/breadbee/a/breadbee_buildroot/buildroot'... Cloning into '/home/alma/Desktop/breadbee/a/breadbee_buildroot/buildroot_rescue'... Submodule path 'br2autosshkey': checked out '6a5780c895eb05c72e182f868157121fdfa16ad5' Submodule path 'br2sanetime': checked out '217bc32687c5ffaf186beb13449138a1106d970d' fatal: remote error: upload-pack: not our ref 12db5d048e9b1c6c5428fbba2c1c6b49f2642321 fatal: Fetched in submodule path 'buildroot', but it did not contain 12db5d048e9b1c6c5428fbba2c1c6b49f2642321. Direct fetching of that commit failed. make: *** [Makefile:71: bootstrap] Error 128
But if I download it from here (the master branch), then the bootstrap and build run just fine.
But I’m getting the same kernel panic as last time:
Starting kernel ... [ 0.228560] dummy-irq: no IRQ given. Use irq=N [ 0.236706] msc313-rtc 1f002400.rtc: hctosys: unable to read the hardware clock [ 0.257028] ------------[ cut here ]------------ [ 0.261693] kernel BUG at crypto/algapi.c:461! [ 0.266157] Internal error: Oops - BUG: 0 [#1] ARM [ 0.270971] CPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0 #1 [ 0.276742] Hardware name: MStar/Sigmastar Armv7 (Device Tree) [ 0.282593] PC is at crypto_unregister_alg+0xbc/0xcc [ 0.287592] LR is at up_write+0x18/0x2c [ 0.291452] pc : [<c0248350>] lr : [<c0143008>] psr: 20000053 [ 0.297741] sp : c0c3beb8 ip : 00000000 fp : 00000000 [ 0.302983] r10: c0601808 r9 : c0893000 r8 : c072085c [ 0.308228] r7 : c08932e8 r6 : 00000001 r5 : 00000000 r4 : c0eca080 [ 0.314778] r3 : 00000002 r2 : 00000000 r1 : c0878a0c r0 : 00000001 [ 0.321330] Flags: nzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment user [ 0.328582] Control: 10c53c7d Table: 20004059 DAC: 00000055 [ 0.334349] Register r0 information: non-paged memory [ 0.339431] Register r1 information: non-slab/vmalloc memory [ 0.345116] Register r2 information: NULL pointer [ 0.349839] Register r3 information: non-paged memory [ 0.354912] Register r4 information: slab kmalloc-512 start c0eca000 pointer offset 128 size 512 [ 0.363751] Register r5 information: NULL pointer [ 0.368476] Register r6 information: non-paged memory [ 0.373549] Register r7 information: non-slab/vmalloc memory [ 0.379231] Register r8 information: non-slab/vmalloc memory [ 0.384913] Register r9 information: non-slab/vmalloc memory [ 0.390597] Register r10 information: non-slab/vmalloc memory [ 0.396365] Register r11 information: NULL pointer [ 0.401178] Register r12 information: NULL pointer [ 0.405989] Process swapper (pid: 1, stack limit = 0x(ptrval)) [ 0.411846] Stack: (0xc0c3beb8 to 0xc0c3c000) [ 0.416223] bea0: c08091ea c024a644 [ 0.424433] bec0: c0c3bec0 c0c3bec0 00002080 c0eca000 c08932ec c0253c44 00000000 c0112218 [ 0.432643] bee0: fffffffe c0809180 00000001 c07075f8 c0707594 ffffe000 00000000 c0893000 [ 0.440853] bf00: c072085c c0700f60 00000000 c06021b8 c0c5a200 c05e0bae 00000000 c01343d8 [ 0.449063] bf20: c05c5be9 c0601808 00000271 00000007 00000007 00000136 c0c5a255 c0c5a269 [ 0.457273] bf40: c0701164 00000007 0000007d c0c5a200 c072083c 00000008 0000007d c0c5a200 [ 0.465481] bf60: c072083c c0701244 00000007 00000007 00000000 c07003d8 00000000 c072a568 [ 0.473690] bf80: 00000000 c0804200 c04cc63c 00000000 00000000 00000000 00000000 00000000 [ 0.481898] bfa0: 00000000 c04cc650 00000000 c0100140 00000000 00000000 00000000 00000000 [ 0.490105] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 0.498312] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 0.506526] [<c0248350>] (crypto_unregister_alg) from [<c0253c44>] (simd_skcipher_free+0x10/0x1c) [ 0.515449] [<c0253c44>] (simd_skcipher_free) from [<c0112218>] (aes_exit+0x1c/0x40) [ 0.523239] [<c0112218>] (aes_exit) from [<c07075f8>] (aes_init+0x64/0x90) [ 0.530154] [<c07075f8>] (aes_init) from [<c0700f60>] (do_one_initcall+0x64/0x15c) [ 0.537767] [<c0700f60>] (do_one_initcall) from [<c0701244>] (kernel_init_freeable+0x198/0x1dc) [ 0.546508] [<c0701244>] (kernel_init_freeable) from [<c04cc650>] (kernel_init+0x14/0x128) [ 0.554818] [<c04cc650>] (kernel_init) from [<c0100140>] (ret_from_fork+0x14/0x34) [ 0.562428] Exception stack(0xc0c3bfb0 to 0xc0c3bff8) [ 0.567503] bfa0: 00000000 00000000 00000000 00000000 [ 0.575712] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 0.583919] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 0.590562] Code: eafffff5 e5943024 e3530001 0afffff4 (e7f001f2) [ 0.596689] ---[ end trace e993a4fe97d607ee ]--- [ 0.601405] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 0.609102] Rebooting in 10 seconds..
Last time I managed to boot by messing around with the Ubuntu versions, but now even that didn’t work. I tried lowering the GCC version to 8.x in the toolchain section of buildroot-menuconfig and set the Custom kernel headers series to 5.7.x, and I didn’t change anything else, but I’m still having the same problem.
Right now, I’m building on the latest Lubuntu distro without any issues.
Do you have any idea what the problem might be?
Sorry again for the trouble.EDIT: I know you sent me a working image, and I could just overwrite the rootfs, but I'd like to build it from scratch.
Hi,
I haven't touched this stuff for ages. I think we should maybe try a rebase up to a mainline kernel and going from there. I might have some time at the weekend to try that out.
Sounds good, thanks a lot!
I’d also like to ask if downgrading the GCC version and the custom kernel headers series might help with my problem?
Also, I checked the kernel repo and saw that there’s mstar_v5_17_rebase, so I tried to switch to it in menuconfig (it’s set to v5_16 by default), but I just can’t seem to change it.
Do you think I should keep struggling with it? Could this be a solution to my kernel panic?
Hi! @fifteenhex
I tried messing around with it a bit, and here’s what I found:
If I comment out this line in the linux.config file in the br2breadbee directory: # CONFIG_CRYPTO_AES_ARM_BS is not set (previously CONFIG_CRYPTO_AES_ARM_BS=y ), it gets past the crypto init bug.However, now I got this wonderful error:
na most ott nem akadt meg, helyette ez van most:SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB device 0 offset 0x80000, size 0x300000 SF: 3145728 bytes @ 0x80000 Read: OK ## Loading kernel from FIT Image at 22000000 ... Using 'breadbee' configuration Trying 'kernel-0' kernel subimage Description: unavailable Type: Kernel Image Compression: uncompressed Data Start: 0x220000a8 Data Size: 2060912 Bytes = 2 MiB Architecture: ARM OS: Linux Load Address: 0x22800000 Entry Point: 0x22800000 Hash algo: crc32 Hash value: a444ed59 Hash algo: sha1 Hash value: 27b14152a05a913dbc72987bd62b99f047403fd6 Verifying Hash Integrity ... crc32+ sha1+ OK ## Loading fdt from FIT Image at 22000000 ... Using 'breadbee' configuration Trying 'fdt-0' fdt subimage Description: unavailable Type: Flat Device Tree Compression: uncompressed Data Start: 0x221f7418 Data Size: 31775 Bytes = 31 KiB Architecture: ARM Load Address: 0x23000000 Hash algo: crc32 Hash value: e72b4ecd Hash algo: sha1 Hash value: 06c5cf4e18254772024f6fdad4af15fa967f96d5 Verifying Hash Integrity ... crc32+ sha1+ OK Loading fdt from 0x221f7418 to 0x23000000 Booting using the fdt blob at 0x23000000 Loading Kernel Image Loading Device Tree to 22f9d000, end 22fa7c1e ... OK Starting kernel ... [ 0.227328] dummy-irq: no IRQ given. Use irq=N [ 0.235492] msc313-rtc 1f002400.rtc: hctosys: unable to read the hardware clock [ 10.726779] spi_master spi0: timeout waiting for dma, lock up in comingand after that, it freezes completely.
Do you have any idea what the new problem might be?
Hi @fifteenhex !
I finally managed to boot it up.
The solution to the SPI lock issue was to remove these lines from kernel.config:CONFIG_DMADEVICES=y # CONFIG_MSTAR_MSC313_BDMA is not set # CONFIG_MSTAR_MSC313_CMDQ is not set # CONFIG_DMATEST is not set # CONFIG_DMADEVICES_DEBUG is not set # CONFIG_DMADEVICES_VDEBUG is not set
Does this error and the crypto error depend on the drivers or on my hardware?
I played around a bit with the GPIOs and tried testing the UART as well, but by default only ttys0 is enabled, which is where the debug output goes. So I tried to set UART1 in the pinmux in beecfg, but I couldn’t get it to work. I tried as root, but when saving it said:
Cannot read environment, using default Cannot read default environment from file.
Without root, it said: Configuration file wrong or corrupted.
This is what I selected in the pinmux settings:
I tried looking for where this file might be, but I couldn’t find it. How can I enable or use UART1, UART2, or one of the SPI ports?I’m sending the dmesg output in case it helps: https://pastebin.com/ftTt7vHU
Thanks in advance!
Hi @fifteenhex !
I tried to figure out what the problem might be, and this is what I came up with (it doesn't mean I'm right, I'm just guessing):
I tried to interpret beecfg as best I could, and it actually just sets the bb_config parameter in env for pinmux, etc. And I was able to replicate the error I sent in the previous message when I tried to run commands like fw_printenv, fw_saveenv, and others. At that point, it produced exactly the same output as beecfg. I thought I’d check if printenv, saveenv, etc., work in uboot... But specifically, everything works except for saveenv, which gives this error:
=> sf probe SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB => saveenv Saving Environment to SPIFlash... Erasing SPI flash...Failed (-22)
So, in my opinion, it’s a bit like nobody can save the env, but the booted Linux can’t even read it.
Do you have any idea what settings I should adjust?
The whole beecfg thing is a bit janky/unfinished but basically its creating a list of overlays for u-boot to apply and saving that into an environment variable. So if even u-boot can't write it that would explain a lot.. I'm thinking that maybe your flash has write protect on some of the blocks? I think there is a command in u-boot to remove that. sf protect unlock <offset> <len> according to a quick google.
Hi @fifteenhex !
I tried, but it gives the same error in both Uboot and the booted Linux.
Error:=> sf protect unlock 0 0x4000 => saveenv Saving Environment to SPIFlash... Erasing SPI flash...Failed (-22)
It seems like there's something wrong with the offset, block size, or erase size.
Hi, sorry for the delay on this. Give me a bit more time. working on porting fresh u-boot and linux.
Hi!
I was messing around a bit and I think I managed to fix the beecfg issue—at least the one I was having.
My problem was that neither beecfg nor uboot could save to the env. The solution was to adjust the env size because, for some reason, it couldn’t save to two sectors on my system. In the end, this is what worked for me:CONFIG_ENV_OFFSET=0x2000 CONFIG_ENV_SIZE=0x1000 CONFIG_ENV_SECT_SIZE=0x1000
After that, I had a small issue with the bb_config and overlay names; even though I enabled it for uart1, I got this in the log: pinctrl-msc313: invalid group 'fuart_cts_rts' for function 'uart1'
The solution was that the FIT overlay only had status=okay, but it pointed to the wrong name in the base DTB.I also played around with the GPIOs and found a few that I couldn’t control for some reason.
"dmesg: pin 43 is not registered so it cannot be requested
gpioget: Invalid argument"
What worked for me was a kernel patch that changed the GPIO order.
GPIO order: FUART, SR_IO, SD, I2C1, SPI0 :<&pinctrl 0 36 4>, <&pinctrl 4 44 16>, <&pinctrl 20 68 6>, <&pinctrl 26 41 2>, <&pinctrl 28 63 4>
I hope this helped a little.
Hello,
I'm so desperate that I had no other idea where to ask for help, so I'll try here.
I built a breadbee myself and everything is in place/everything is soldered in perfectly and everything was there. Even windows recognizes the CH340E but no data comes in on the UART. I tried various SPI NOR chips and finally settled on the W25Q256FV due to the large memory capacity of the chip. I even managed to run buildroot for the 5th time to generate the image I could write to the SPI chip but before that I converted it to a .bin file.
But after that I don't have much idea what could be wrong.
Anyone have any ideas?
Thanks in advance!