Network booted RPI 3B+ modprobe bcm2835-v4l2 freezes machine #2528
Comments
|
Just tried upgrading Still freezes machine, Keyboard unresponsive, does not ping etc etc... |
|
Did an rpi-update, still same, tried a couple of different PSU for good luck as well |
|
This looks like a duplicate of #2335 (ignore the title). |
|
Testing with a 3B+ booting from SD card but with an NFS root partition I see no problems - it just works. Are you booting: |
|
Now tested with a fully network-booted 3B+ - again, no problems. |
|
With #2335 I did have it failing on a 2 or 3B with only bootcode.bin on the SD card and talking to PiServer. |
|
Updated my PiServer from 4.9.xx to 4.14.34 (latest from apt). |
No SD card. I have firmware in a directory with the name of the Pi serial number "25bcbfa6"
Board is a Pi 3B+, yes with the camera attached. The idea is to have NFS booted cameras, I have purchases 10 camera modules so it would be great if this could be sorted. I assure the issue is real and can provide unexciting video if needs be. |
|
pelwell's just confirmed that he had no camera attached, so that sort of confirms my earlier debug. I have seen a little mismatch in resource allocation/free, but don't see how that would cause these issues. It's odd as there isn't anything fundamentally different between SD card and network booting. |
|
I can also confirm that it wedges with a camera attached. With some VCHIQ logging enabled at the same I see the following kernel logging: Note the (presumably fatal) dwc_otg messages, and the subsequent NFS death. |
|
|
Any update on this ? I did an rpi-update, now running This is much the same, except it returns the prompt before crashing after "modprobe bcm2835-v4l2" . PS this new kernel/firmware version is slightly less reliable NFS booting than before. Sometimes stops on the IP details summary and fails to continue..... odd ... Thanks, |
|
18 days zero comments. Am I correct that the issue is within the Broadcom binary b******ks (tm)? I am assuming this is not an issue I can investigate ? |
|
Sorry, busy on other issues/tasks. It got an initial triage and is now in the queue to investigate.
Incorrect as noted in #2335 (comment) |
Ok, I will have a look, what is the best place to browse the source of the specific RPI shipped version of the "bcm2835-v4l2" module ? I don't know how the vc code interacts with the kernel code. |
Compiled the following as "bcmhi", when run before the modprobe on the NFS booted machine the module loads ok. I noticed this on the debug output above. Doesn't the CSI interface depend on an ISR resident in the vc code ? [ 123.283885] WARN::dwc_otg_hcd_handle_hc_fsm:2458: Unexpected IRQ state on FSM transaction:dev_addr=4 ep=2 fsm=6, hcint=0x00000002 Thanks, |
OK, so confirmed as a duplicate of #2335 then.
??! How did you get from an error message from the USB driver (dwc_otg) to worrying over interrupts from the camera? |
|
"ARM and VPU have independent interrupt controllers" |
Although the first stage would be to copy/paste the implementation of bcm_host_init into your app to see how far through you need to go to make the module loading work correctly. Once you've done that, then start following the last required call down (or just report back as you'll have saved us a good half hour or so of debug). |
|
http://jonshouse.co.uk/bcmhi.tar.gz I copied some bits around, no makefile "./compile" generates a binary "bcmhi" In bcm_host.c i modified bcm_host_init(), adding a printf. I move the return down the function one call at a time re-booting between each attempt, reached pretty much the end of the function before the modprobe worked. Output looked liked this: Not sure if that helps, I cant see source for vc_gencmd() so I assume that is as far as I can follow that line ? |
|
Found vc_gencmd() ... seems github search does not show the function definition in preference to callers... will egrerp -r locally instead from now on, me bad ... |
|
I've finally had a chance to dig into this. The minimum set of stuff from bcm_host_init is The camera component does query VLLs, so I suspect that something in the internal "filesystem" on the VPU is blowing up due to not having the VLL directory set sensibly. I'll trace it further in the firmware now. |
|
Firmware patch created to fix this issue. It'll be reviewed internally, but I'd expect it to be in the next rpi-update release. |
…era stages See: raspberrypi/linux#2528 firmware: bootcode: Force an I2C stop as a reset firmware: power: Ensure at least 2ms between writes to the PMIC regs firmware: power: Add 3ms threshold firmware: power: Reduce i2c speed of pmic to 100kHz
…era stages See: raspberrypi/linux#2528 firmware: bootcode: Force an I2C stop as a reset firmware: power: Ensure at least 2ms between writes to the PMIC regs firmware: power: Add 3ms threshold firmware: power: Reduce i2c speed of pmic to 100kHz
|
Workaround was merged 5 June, released via rpi-update 7 June. |
|
This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested. |
JamesH65
added
the
Close within 30 days
|
I am trying to figure out how to update the NFS root image without backtracking to the original SD card image then copying it all back over. I get this super crap error (invalid hash of what?, from where? referenced by what ?) |
|
You're on a network booted system so need to update the files that your TFTP server is handing out. Go to https://github.com/Hexxeh/rpi-firmware, download the start*.elf files and fixup.* files, and put them in the directory that your TFTP server is using. Reboot the Pi. The firmware should now all be updated, and hopefully the issue resolved. |
|
Alternatively you can (if your TFTP server is sharing its files) mount the TFTP server directory for your Pi on /boot and use rpi-update as usual. |
|
"You're on a network booted system so need to update the files that your TFTP server is handing out." I login to the NFS booted Pi via ssh - as default it is read only I issue Check it Yep, it is read/write ok. My NFS root has a "/boot" this is the same contents as the firmware directory the Pi booted from Now rpi-update can see a normal read/write "/" and a true representation of "/boot" - in the past I simply ran rpi-update at this point and all was good, then copied the firmware back into the serial number directory. |
|
|
One thing to be aware of is that this won't update the bootcode.bin downloaded by the bootrom, which doesn't support the serial number subdirectories, |
Sorry, I don't understand. Isn't the bootcode.bin the same binary however it is loaded by the Pi... what does not support the serial number subdirectories?, you have lost me at this point. |
|
When the boot ROM downloads bootcode.bin from the TFTP server (as a 3B+ can when booting with no SD card) it only looks for |
|
"when actually you were just overwriting /bootcode.bin." Glad you mentioned that, I was looking at the ftfboot directory just now thinking I must delete some of these stray files.... |
|
Yay ... Thanks :-) |
|
PS I uploaded the camera client/server code to github for safe keeping, bit rough at the moment, but works ok. It looks static on the video but is updating 14 frames a second. My next job is top try and figure out how to write my date/time stamp over the camera frame then have the Pi jpeg encode the result. At the moment I use v4l to read the frame as YUV, convert to RGB, overlay the text then jpeg encode and send the image to the server. Linux desktop viewer. The code, server, client and desktop apps. |
Eek! Why do people hate YUV so much? It's a slight shame that you chose to use V4L2, as the camera subsystem can do basic annotations, as demonstrated in https://www.youtube.com/watch?v=WnnKrVSMbng. They're always top and centre at the moment as I haven't had the inclination to add the plumbing to move it around. |
Nice demo video :-) I have an RPI specific version of the camera code, that use v4l at the moment but can work in any way the Pi is happy with. It uses memory mapped I/O to read the state of the IR light level and to toggle the IRCUT filter on the camera module I am using, so it is non portable at that point: What I really need from an API is just a way to scribble into the framebuffer between the camera capture and some form of hrdware Jpeg encode. Does any API exist for my to plug into the YUV buffer and still let the Pi hardware encode the jpeg. I did look for demos/code and did not come up with a great deal. I could not find any good examples of encoding a camera jpeg on the Pi video engine for example, I only want one jpeg at a time as I need to decide to send it or drop it depending on network conditions. I am using TCP and cant afford for the buffer to bloat to the point it becomes non real-time. As for RGB24 rather than YUV, it's mostly because I can work with RGB in my head hence that is what most of my code references, I can probably work with YUV but only with several google pages open ;-) |
|
It has been so long since I looked at this, I was wrong, the generic V4l code uses YUV if opening the device for RGB fails OR (and it is an important or) the size of the RGB image is wrong. Seems V4l has a fault on some cameras, claims it opens in RGB but does not, in that case the code 'falls back' to YUV and adds a conversion to RGB. Video of configuration tool, changes server settings and also passes settings to any connected cameras. |
… fixes: - firmware: config: Add gpio command See: #955 - firmware: hat_lib: Only probe HAT EEPROM if ID pins are inputs - firmware: Added a arm_display_kick function - firmware: Possible fix for HDMI audio pause See: #547 - firmware: arm_loader: Always set the turbo frequencies immediately See: #956 - firmware: platform: Partial revert for eemc clock change for slice See: https://forum.libreelec.tv/thread/11930-libreelec-8-2-4-causes-slice-3-to-hang/ - firmware: clockman: Don't use OSC for pixel clock See: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=24679&start=150#p1297298 - firmware: config: gpio - Allow pn (pull none) as alternative to np (no pull) - firmware: arm_loader: Use a wrapper to set clocks either through turbo or non-turbo interfaces See: #967 - firmware: platform: Allow vec pll to be adjusted See: #960 - firmware: platform: Pi3 B+ reduce sdram freq to 450 while investigations are ongoing See: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=208821 - firmware: arm_loader: Allow hdmi_ignore_composite to disable any display initialisation See: raspberrypi/userland#447 - firmware: Add aphy and dphy slew and drive register controls - firmware: Extra reg writes to ensure the LCD display starts up at 800 wide - firmware: platform: Lower temperature thresholds for extra pips to 50/60 - firmware: video_encode: Add support for YVU420Planar and YVU420SemiPlanar - firmware: video_decode: Support YV12, NV12, and NV21 output - firmware: video_decode: Support reporting colour space - firmware: IL rawcam: Fix copy/paste error on timing setup - firmware: MMAL: Populate buffer header TYPE_SPECIFIC fields - firmware: video_encode: Filter the list of encoders based on variant - firmware: mmal: Relax requirement on a buffer in mmal_port_send_buffer - firmware: platform: avs: Also apply chicken bits to boost voltage - firmware: Match phy setup same as bootcode for device mode initialisation - firmware: Add logging_messages to UART - bootcode: Fix 3B+ bootcode.bin only booting - firmware: vc_image: vc_image_fill_yuv_uv sometimes overfilled the first column See: raspberrypi/userland#465 - firmware: arm_loader: Add SET_NOTIFY_REBOOT message See: #968 - firmware: gencmd: Report temperature with read_ring_osc values - firmware: mmal_ril: Correct portdef assignment for video.eColorFormat - firmware: variants: Add TGA and PPM codecs - firmware: imx219: Fix exposure calcs for rounding down - firmware: sdram: Remove [ad]phy_drv_slew logging spam - firmware: sdram: Reduce address skew from -10 to -5 - firmware: platform: Avoid improving the schmoo on Pi3+ - firmware: platform: Latest AVS rules - firmware: sdram: Increase read/write latency for higher sdram frequencies - firmware: power: Add boot-time 3b+ PMIC register logging - firmware: power: Continue to probe PMIC after error - revert: sdram: Reduce address skew from -10 to -5 See: https://forum.kodi.tv/showthread.php?tid=298461&pid=2740277#pid2740277 - firmware: variant: Disable custom_preproc and focus_stats_preproc camera stages See: raspberrypi/linux#2528 - firmware: bootcode: Force an I2C stop as a reset - firmware: power: Ensure at least 2ms between writes to the PMIC regs - firmware: power: Add 3ms threshold - firmware: power: Reduce i2c speed of pmic to 100kHz - firmware: dtoverlay: More "reg" and "name" support - firmware: imx219: Updates for production test - firmware: arm_loader: Update NOTIFY_REBOOT to reset the GPIO expander See: #968 - firmware: Allow selection of DSI port for LCD - firmware: pwm_sdm: fix an edge case when reading back DMA source addresses - firmware: pwm_sdm: fix write handle refcounting See: raspberrypi/linux#2587 - firmware: arm_dt: Protect against seg-fault when dt failed to load - firmware: isp: Alter logging level for buffer size errors - firmware: isp: Return output buffers that are too small - firmware: video_encode: Integrate the ISP for format conversion - firmware: mmal: Populate buffer->type->video.flags field - firmware: image_fx: Apply interlacing flags from the plugin to output frames - firmware: isp: IL compatibility and alignment tweaks - firmware: IL ISP: Use vc_image instead of reworking own stride checking - firmware: isp: Minor clean ups - firmware: dispmanx: Complete the format strings for dispmanx_parse_list - firmware: IL ISP: Use vc_image instead of reworking own stride checking - firmware: MMAL/IL: Add support for components to report alignment requirements
JamesH65
removed
the
Close within 30 days
|
Closing this issue as questions answered/issue resolved. |
NFS root RPI3B+
I have a working card image, works with my v4l app, camera works fine.
I made a network booting image of the same files, boots ok its just now it hard locks loading the module. Modprobe of other modules is ok.
Linux raspberrypi 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 GMT 2018 armv7l GNU/Linux
I can switch between booting form the sd card or the LAN, sdcard always works, LAN boot always locks if I try and load the module.
Even tried copying the modules to a tempfs mount point and using "modprobe -d", still locks up.
The text was updated successfully, but these errors were encountered: